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

On 2012-03-05 00:40, O. Hartmann wrote:
...
> 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"?

None.  These variables are not part of the build system.  They are just
a suggestion posted by people on the mailing list.  You must still use a
statement somewhere that adds one of the variables to the "real" CFLAGS,
and that statement will need knowledge about what "cc" is.

Note, I would suggest using the names CFLAGS.gcc and CFLAGS.clang
instead.


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

See above.


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

I'm not sure what you mean with "confuse"?  The settings in make.conf
are read earlier than those in src.conf, so the latter can override the
former.

Also, the settings in make.conf are *always* read, even if you are using
a non-BSD Makefile (one that doesn't contain .include <bsd.prog.mk> or
similar at the end).


...
>>> 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.

I have compiled multiple worlds now from the latest trunk, with both gcc
and clang, but I have not been able to reproduce your errors yet.