CLANG buildworld failure: lint: cannot exec /usr/obj/usr/src/tmp/usr/bin/cc: No such file or directory

O. Hartmann ohartman at
Sun Mar 4 23:40:15 UTC 2012

On 03/04/12 22:46, Dimitry Andric wrote:
> On 2012-03-04 21:34, O. Hartmann wrote:
> ...
>> Where are those new "WITH_CLANG_XXXX" tags documented?
> In src.conf(5), where all the WITH_ and WITHOUT_ settings are
> documented.
> I should probably have sent a heads up to this list, to announce this
> new setting, which installs clang as /usr/bin/cc, /usr/bin/c++ and
> /usr/bin/cpp, effectively making it the "default compiler".
> That said, I made a mistake in r232322, which introduced the setting,
> causing gcc not to be built at all if you had all default settings,
> except CC=clang, CXX=clang++ and CPP=clang-cpp.
> This caused no 'cc', 'c++' and 'cpp' executables to be installed under
> the temporary object tree.  It should theoretically work, but some tools
> like lint still have 'cc' hardcoded, and thus they fail.
> I have worked around this in r232522.  Please update to that revision,
> and try again.

All right, my /etc/src.conf looks like this now (as it does before):

WITH_CLANG=             YES
WITH_IDEA=              YES
WITH_HESIOD=            YES
#WITH_ICONV=            YES
#WITH_OFED=             YES

When cc is now clang, c++ is now clang++, what effect do have"blablabla" and CFLAGS.clang="blabla"?

If the binary "cc" after this treatment is in reality "clang", then
logic implies that equality exists: = CFLAGS.clang = "blabla"

What should /etc/make.conf contain not to confuse settings in

I commented for now out everything that was recommended to be set when
one wants to use CLANG as the default compiler. My binary /usr/bin/cc
reports itself still to be gcc 4.2.1, so cc = gcc-4.2.1.

My system is at 10.0-CURRENT #0 r232497. My sources, which are
impossible to build now, are at Revision: 232526.

>> In my case things developed even worse. After the last "make update" in
>> /usr/src (SVN based), I can't even build a kernel (make buildworld fails
>> very early):
>> ===> games/fortune/strfile (obj,depend,all,install)
>> /usr/obj/usr/src/tmp/usr/src/games/fortune/strfile created for
>> /usr/src/games/fortune/strfile
>> rm -f .depend
>> CC='clang' mkdep -f .depend -a
>> -I/usr/obj/usr/src/tmp/legacy/usr/include -std=gnu99
>> /usr/src/games/fortune/strfile/strfile.c
>> echo strfile: /usr/lib/libc.a
>> /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> .depend
>> clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -std=gnu99
>> -I/usr/obj/usr/src/tmp/legacy/usr/include -c
>> /usr/src/games/fortune/strfile/strfile.c
>> clang -O2 -pipe -O2 -fno-strict-aliasing -pipe -std=gnu99
>> -I/usr/obj/usr/src/tmp/legacy/usr/include  -static
>> -L/usr/obj/usr/src/tmp/legacy/usr/lib -o strfile strfile.o -legacy
>> clang: warning: argument unused during compilation: '-std=gnu99'
>> strfile.o: In function `main':
>> /usr/src/games/fortune/strfile/strfile.c:(.text+0x2e0): undefined
>> reference to `_ThreadRuneLocale'
> This is unrelated to the 'cc' problem, but I suggest deleting /usr/obj/*
> and starting the build from scratch.

Before I start "make buildworld", I always delete the content of
/usr/obj/*, so there are never remains aof anything left behinf from
earlier compiles.

You're right, this is at the first sight unrelated to the cc issue and
should be treated separetely.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
Url :

More information about the freebsd-current mailing list