Date: Mon, 05 Mar 2012 00:40:07 +0100 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: Dimitry Andric <dim@FreeBSD.org> Cc: Pegasus Mc Cleaft <ken@mthelicon.com>, freebsd-current@freebsd.org Subject: Re: CLANG buildworld failure: lint: cannot exec /usr/obj/usr/src/tmp/usr/bin/cc: No such file or directory Message-ID: <4F53FD57.303@zedat.fu-berlin.de> In-Reply-To: <4F53E2C3.7090102@FreeBSD.org> References: <4F536D41.1030302@zedat.fu-berlin.de> <201203041628.q24GS12l088270@pozo.com> <201203041751.02531.ken@mthelicon.com> <4F53D1D3.2010607@zedat.fu-berlin.de> <4F53E2C3.7090102@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3541D255F97D09306D65FB7D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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? >=20 > In src.conf(5), where all the WITH_ and WITHOUT_ settings are > documented. >=20 > 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". >=20 > 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=3Dclang, CXX=3Dclang++ and CPP=3Dclang-cpp. >=20 > This caused no 'cc', 'c++' and 'cpp' executables to be installed under > the temporary object tree. It should theoretically work, but some tool= s > like lint still have 'cc' hardcoded, and thus they fail. >=20 > 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=3D YES WITH_CLANG_EXTRAS=3D YES # WITH_BIND_LIBS=3D YES WITH_BIND_SIGCHASE=3D YES WITH_BIND_LARGE_FILE=3D YES # WITH_IDEA=3D YES WITH_HESIOD=3D YES # #WITH_ICONV=3D YES #WITH_BSD_GREP=3D YES # WITH_LIBCPLUSPLUS=3D YES # #WITH_OFED=3D YES When cc is now clang, c++ is now clang++, what effect do have CFLAGS.cc=3D"blablabla" and CFLAGS.clang=3D"blabla"? If the binary "cc" after this treatment is in reality "clang", then logic implies that equality exists: CFLAGS.cc =3D CFLAGS.clang =3D "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 =3D 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. >=20 >=20 >> In my case things developed even worse. After the last "make update" i= n >> /usr/src (SVN based), I can't even build a kernel (make buildworld fai= ls >> very early): >> >> =3D=3D=3D> 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=3D'clang' mkdep -f .depend -a >> -I/usr/obj/usr/src/tmp/legacy/usr/include -std=3Dgnu99 >> /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=3Dgnu99 >> -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=3Dgnu99 >> -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=3Dgnu99' >> strfile.o: In function `main': >> /usr/src/games/fortune/strfile/strfile.c:(.text+0x2e0): undefined >> reference to `_ThreadRuneLocale' >=20 > This is unrelated to the 'cc' problem, but I suggest deleting /usr/obj/= * > and starting the build from scratch. >=20 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 --------------enig3541D255F97D09306D65FB7D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBAgAGBQJPU/1dAAoJEOgBcD7A/5N88AoIANh2rq1H+m6WhdS1opruh/4r HXMRa3P6Qm1gvAJv31m26RMAT+p/z61+23JaK3tXqi9xa9s9veQmR7wm67U5sv9K 0DT9uQf8sOJFg41Ucn5YUrAAgd3aCe65GIUpuFL2gEJTb8QSwTJmu9EGGE3owNnv liC9+BHPzTJToxtEQmSVCuN+WhpVTnBvymAmfhMbuKekdkPoFVXii6d04EFGTSQW rQ3bXPkXPih62AQ8eqiLFv4itCqK2zldxBpeltfLI5/CUARvvONVHrczjAjH1GR2 YIRkIrjYMagaZEJbjQnF3Itay9GVVDUNyLyeWCmtJBR60G1iz/CY0nCEGZawp80= =se84 -----END PGP SIGNATURE----- --------------enig3541D255F97D09306D65FB7D--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F53FD57.303>