buildworld failure, as not found

olafz

olafz

Hello,

I have no idea what's going on here. I am trying to build world with llvm60 and binutils from ports.
Code: 
===> 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:
Code: 
# which as
/usr/local/bin/as
And manually building works:
Code: 
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
 
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?
 
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:

Code: 
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
 
Well I doubt this is supported, and I don't get the point -- there's always
Code: 
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 :)
 
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.)
 
Thank you for that brief explanation. In fact, there seems to be no variable to define AS in make.conf():
Code: 
# 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
 
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?
 
  • Thanks
Reactions: PMc
It is out of curiousity: is it possible to build a system without build tools using an external toolchain.
 
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.
 
You must log in or register to reply here.
Back
Top