Well, I got conclusive results. It's possible to do this but I wouldn't bother because it has the potential to 'break' your system, at least some parts of it.
So in the mean time I finally got around to customizing my new FreeBSD server and because the system already had
devel/llvm40 installed I figured I could do without the base Clang version.
So I added this in
/etc/src.conf:
Code:
WITHOUT_CLANG=
WITHOUT_CLANG_BOOTSTRAP=
... and then continued to build my entire system. Everything worked without any flaws. Building, installation, it's all perfect. Except it's not.
First thing which puzzled me was that Clang was still part of my base system while at the same time it also wasn't:
Code:
omicron:/home/peter $ file `which cc`
/usr/bin/cc: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 11.1, FreeBSD-style, stripped
omicron:/home/peter $ ls /usr/lib/clang
ls: /usr/lib/clang: No such file or directory
I didn't give this much thought until I started getting errors during the build of some ports. I was puzzled at first but soon discovered the origin of these errors.
This is while building
security/nss:
Code:
In file included from ctr.c:17:
./rijndael.h:21:10: fatal error: 'emmintrin.h' file not found
#include <emmintrin.h> /* __m128i */
^~~~~~~~~~~~~
1 error generated.
gmake[5]: *** [../../coreconf/rules.mk:393: FreeBSD11.1_OPT.OBJ/FreeBSD_SINGLE_SHLIB/ctr.o] Error 1
gmake[5]: Leaving directory '/usr/ports/security/nss/work/nss-3.34/nss/lib/freebl'
Research learned me that the file
emmintrin.h used to be located in
/usr/lib/clang/4.0.0, a directory which is now removed.
The file is still located on my system, but its current location is
/usr/local/llvm40/lib/clang/4.0.1/include/immintrin.h, a place where it apparently can't be found. Not too surprising if you ask me, especially when you keep this aspect in mind:
Code:
omicron:/home/peter $ cc -v
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
Target: x86_64-unknown-freebsd11.1
Thread model: posix
InstalledDir: /usr/bin
So then I concluded that this is giving me more trouble than it's worth, as such I decided I'd rebuild my base system, included Clang again, and all would be back to normal.
Yah, but there is a flaw in that line of reasoning, because although the base system will indeed bootstrap itself to build its own set of tools, it'll need a working compiler to compile its own stuff first.
And apparently I don't have one right now:
Code:
--- kerberos5/lib/libheimbase__L ---
ctfconvert -L VERSION -g heimbase.pico
--- null.pico ---
/usr/local/bin/ccache cc -target x86_64-unknown-freebsd11.1 --sysroot=/usr/obj/u
sr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -fpic -DPIC -g -O2 -pipe -I/usr/src/cr
ypto/heimdal/include -DHAVE_CONFIG_H -I/usr/src/kerberos5/include -MD -MF.dep
end.null.pico -MTnull.pico -std=gnu99 -fstack-protector-strong -Qunused-argum
ents -c /usr/src/crypto/heimdal/base/null.c -o null.pico
--- secure/lib/libcrypto__L ---
ctfconvert -L VERSION -g ccm128.o
--- lib/liblzma__L ---
In file included from /usr/src/contrib/xz/src/liblzma/lz/lz_encoder.c:23:
/usr/src/contrib/xz/src/liblzma/common/memcmplen.h:19:11: fatal error: 'immintri
n.h' file not found
# include <immintrin.h>
^~~~~~~~~~~~~
1 error generated.
*** [lz_encoder.o] Error code 1
make[4]: stopped in /usr/src/lib/liblzma
1 error
make[4]: stopped in /usr/src/lib/liblzma
*** [lib/liblzma__L] Error code 2
make[3]: stopped in /usr/src
--- secure/lib/libcrypto__L ---
ERROR: ctfconvert: rc = -1 No entry found [dwarf_next_cu_header_c(61)]
A failure has been detected in another branch of the parallel make
As you can see it's complaining about the exact same file as before.
Therefor this leads me to conclude that it is indeed perfectly possible to build your base system without Clang and without having it bootstrap Clang (the latter is an interesting option because it can save you quite some build time).
However, it can result in a few issues as showcased here which lead up to me concluding that in the end this isn't worth the hassle for regular use.
I think it will be more useful to try and install a 'dummy'
devel/llvm40 port and then try to build those ports which claim to rely on this. So basically tricking them to build against the compiler in the base system and then see what happens next.
The main goal is to save time of course (not having to build Clang twice), but it could also be quite education.
Anyway, hope this can give some people some useful information.
