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

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_CLANG_EXTRAS=      YES
#
WITH_BIND_LIBS=         YES
WITH_BIND_SIGCHASE=     YES
WITH_BIND_LARGE_FILE=   YES
#
WITH_IDEA=              YES
WITH_HESIOD=            YES
#
#WITH_ICONV=            YES
#WITH_BSD_GREP=         YES
#
WITH_LIBCPLUSPLUS=      YES
#
#WITH_OFED=             YES

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

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

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

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.


Regards,
Oliver