# buildworld failure, as not found



## olafz (May 17, 2019)

Hello,

I have no idea what's going on here. I am trying to build world with llvm60 and binutils from ports.

```
===> stand/ficl (all)
===> stand/ficl32 (all)
===> stand/forth (all)
===> stand/liblua (all)
===> stand/liblua32 (all)
===> stand/lua (all)
===> stand/fdt (all)
===> stand/defaults (all)
===> stand/man (all)
===> stand/userboot (all)
===> stand/userboot/test (all)
===> stand/userboot/userboot_4th (all)
===> stand/userboot/userboot_lua (all)
===> stand/i386 (all)
===> stand/i386/mbr (all)
as  --defsym FLAGS=0x80 --32  -o mbr.o /usr/src/stand/i386/mbr/mbr.s
/bin/sh: as: not found
*** Error code 127
```
But as is there:

```
# which as
/usr/local/bin/as
```
And manually building works:

```
root@fb:/usr/src/stand/i386/mbr # make
as  --defsym FLAGS=0x80 --32  -o mbr.o /usr/src/stand/i386/mbr/mbr.s
/usr/local/llvm60/bin/clang -O2 -pipe -I/usr/src/stand/i386/btx/lib -nostdinc -I/usr/obj/usr/src/amd64.amd64/stand/libsa32 -I/usr/src/stand/libsa -D_STANDALONE -I/usr/src/sys -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface -DLOADER_GELI_SUPPORT -I/usr/src/stand/libsa/geli -DLOADER_DISK_SUPPORT -m32 -ffreestanding -mno-mmx -mno-sse -mno-avx -mno-avx2 -msoft-float -march=i386 -I. -DNDEBUG -std=gnu99 -Wsystem-headers -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Oz -Qunused-arguments  -e start -Ttext 0x600 -Wl,-N,-S,--oformat,binary -nostdlib -Wl,--no-rosegment -o mbr mbr.o
machine -> /usr/src/sys/i386/include
x86 -> /usr/src/sys/x86/include
root@fb:/usr/src/stand/i386/mbr # as --defsym FLAGS=0x80 --32 -o mbr.o /usr/src/stand/i386/mbr/mbr.s
root@fb:/usr/src/stand/i386/mbr # l mbr.o
-rw-r--r--  1 root  wheel   1.7K May 17 14:50 mbr.o
```


----------



## zirias@ (May 17, 2019)

olafz said:


> I am trying to build world with llvm60 and binutils from ports.


I don't think that's a supported way of building, base has its own toolchain...


----------



## SirDice (May 17, 2019)

What version of FreeBSD? Where did the source tree come from? What's in /etc/make.conf? And what's the rational of not building it the normal way?


----------



## olafz (May 17, 2019)

I want to customize a 12-RELEASE so that it does not have development components except for the one from ports.
And I assume that this is supported, but I am not sure. I had installed xtoolchain-llvm60 from ports.

make.conf is this one:


```
CC=/usr/local/llvm60/bin/clang
CXX=/usr/local/llvm60/bin/clang++
CPP=/usr/local/llvm60/bin/clang-cpp
LD=/usr/local/llvm60/bin/ld.lld
NM=/usr/local/llvm60/bin/llvm-nm
OBJDUMP=/usr/local/llvm60/bin/llvm-objdump
STRINGS=/usr/local/llvm60/bin/llvm-strings

KERNCONF=FB64
MODULES_OVERRIDE=mac_ntpd filemon
#
OPTIONS_UNSET= NIS
OPTIONS_UNSET+= X11
OPTIONS_UNSET+= DOCS
OPTIONS_UNSET+= DEBUG
OPTIONS_UNSET+= WAYLAND
#
DEFAULT_VERSIONS+= ssl=libressl
DEFAULT_VERSIONS+= python=3.6
```


----------



## zirias@ (May 17, 2019)

Well I doubt this is supported, and I don't get the point -- there's always

```
WITHOUT_TOOLCHAIN=yes
```
if you don't want to _install_ the toolchain, but it will still be used for building. What's the point of using a different toolchain for base?

BTW, I'd recommend putting anything for configuring base in /etc/src.conf instead of /etc/make.conf for a clear separation


----------



## PMc (May 17, 2019)

You probably have to go into that makefile (and the makefile in /usr/src) and debug what path and what tools it actually tries to use at that point.
As, You say, this is a buildworld, it will most likely do some bootstrapping first, i.e. build the tools needed to build world, and then twiddle the path so to use only those tools.

I had a very similar issue yesterday when trying to installworld, I suddenly got the error `env: not found` - while env was obviousely present in the path, and from within the concerned subdirectory the install would succeed. Then I found that there is a specific list of tools that are to be used during install, and these are put into a specific directory first - and "env" was not among them. (The actual mistake was that I had patched my srctree before buildworld, and then again before buildkernel, and so the patches were timestamped newer than the objtree, and during install make tried to build the stuff again.)

Concerning "supported": as i vaguely remember, there is _some_ support for using a foreign toolchain. But this may not be so rock-solid that it would save you from looking into some makefiles for what is actually happening...

And, stupid question: why don't You put Your assembler into make.conf as well? /usr/local/bin is not a standard path. (Just guessing - I am not sure if Your approach works at all or how it is to be tackled; this remains to be tried out.)


----------



## olafz (May 20, 2019)

Thank you for that brief explanation. In fact, there seems to be no variable to define AS in make.conf():

```
# man make.conf|grep AS
                   SASL support with setting such as:
                         SENDMAIL_CFLAGS=-I/usr/local/include -DSASL
FreeBSD 12.0-RELEASE-p3       September 27, 2018       FreeBSD 12.0-RELEASE-p3
```


----------



## zirias@ (May 20, 2019)

Well check the makefiles, they probably use a lot more variables that COULD be overridden in make.conf / src.conf than documented in the manpages. Whether this is a good idea is another question, and I still wonder what you try to achieve by using a foreign toolchain?


----------



## olafz (May 20, 2019)

It is out of curiousity: is it possible to build a system without build tools using an external toolchain.


----------



## zirias@ (May 20, 2019)

Well then, check the Makefile. I really doubt it uses `as` directly in a recipe but some variable instead and there is probably a way to provide this variable from make.conf (or, IMHO better, src.conf). I definitely wouldn't want to use a base built that way for production ...

Again, if the motivation of your experiment is a stripped-down installation, the `WITHOUT_TOOLCHAIN` variable might be what you want to try, maybe along with several other `WITHOUT_XXXX` variables. But then, I'd only use `WITHOUT_TOOLCHAIN=yes` with the `installworld` target on a machine I don't intend to do any building -- ports are normally preferring the host's toolchain for building whereever possible, which gives you some confidence in getting a proven solid build.


----------

