On 03/05/12 08:45, Dimitry Andric wrote: > 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. Ah, I see. Sorry for the noise. I picked up the thread and thought this might be a fact by now. NAd yes, I'd rather follow your suggestion, it makes things more clear. > > >> 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. Since yesterday/today's night, I'm also able to compile again the system. The solution is obscure and a kind of "hoodovoodo" (at least for me). I "updated" backwards the sources via "svn -r 232496 update", then again a simple "make update" in /usr/src. After this procedure the problem vanished. I have no idea what's wrong. Since I thought I might have destroyed my OS by accidentaly interrupting the installation of libc once, were a similar error occured but in another context, I think I'm rather better deleting the /usr/src and doing again an checkout. Something seems very fishy ... Regards, Oliver
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:24 UTC