Re: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
13.09.2013, 01:11, Dimitry Andric d...@freebsd.org: On Sep 12, 2013, at 21:47, S.N.Grigoriev serguey-grigor...@yandex.ru wrote: after upgrading to r255423 (make buildworld make buildkernel make installkernel make installworld reboot; make delete-old make delete-old-libs) I cannot build the system with the WITH_GCC=yes and WITH_GNUCXX=yes options in my src.conf. The following error occures: --- libgssapi_krb5.so.10 --- building shared library libgssapi_krb5.so.10 --- gnu/lib__L --- /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:3: error: use of undeclared identifier '_List_node_base' _List_node_base::swap(_List_node_base __x, _List_node_base __y) ^ I just sent a mail to re@ to get approval for a fix for this. In the mean time, please apply the attached patch. -Dimitry , Hi Dimitry, thank you for your response. Your patch works for me! -- Regards, S.Grigoriev. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
On 11 Sep 2013, at 21:06, David O'Brien obr...@freebsd.org wrote: It is still very useful for folks to test changes in order to help ensure one doesn't break the build on platforms still using GCC. If you want to do this test, then you should do make universe or make tinderbox (you should do one or the other before committing anything already anyway), and these will build the cross-gcc toolchains for various architectures. The GCC in base is not used when build-testing anything except the toolchain with our build system. If you want to test building things with gcc, then you need to build WITHOUT_CLANG_IS_CC (which will build gcc and then build world with it), or explicitly specify a compiler to use when testing a smaller component (which can be a gcc you installed from the base tree, or one from ports - Warner is currently working to ensure that we'll have the FreeBSD-specific patches forward-ported so that each of the lang/gcc ports will be able to build FreeBSD). The change is only to the default install. If you are not a FreeBSD developer, then you are almost certainly not using our gcc: you're either not a developer at all, in which case you're rarely compiling things, or you're a developer of other stuff and therefore want a modern compiler (either clang or lang/gcc). If you are a developer, then a change to the default install should not be a significant obstacle to your configuring the system how you want. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
Hi list, after upgrading to r255423 (make buildworld make buildkernel make installkernel make installworld reboot; make delete-old make delete-old-libs) I cannot build the system with the WITH_GCC=yes and WITH_GNUCXX=yes options in my src.conf. The following error occures: --- libgssapi_krb5.so.10 --- building shared library libgssapi_krb5.so.10 --- gnu/lib__L --- /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:3: error: use of undeclared identifier '_List_node_base' _List_node_base::swap(_List_node_base __x, _List_node_base __y) ^ /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:25: error: use of undeclared identifier '_List_node_base'; did you mean '__list_node_base'? _List_node_base::swap(_List_node_base __x, _List_node_base __y) ^~~ __list_node_base /usr/obj/usr/src/tmp/usr/include/c++/v1/list:190:8: note: '__list_node_base' declared here struct __list_node_base ^ /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:25: error: no template named '_List_node_base'; did you mean '__list_node_base'? _List_node_base::swap(_List_node_base __x, _List_node_base __y) ^~~ __list_node_base /usr/obj/usr/src/tmp/usr/include/c++/v1/list:190:8: note: '__list_node_base' declared here struct __list_node_base ^ /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:25: error: use of class template '__list_node_base' requires template arguments _List_node_base::swap(_List_node_base __x, _List_node_base __y) ^ /usr/obj/usr/src/tmp/usr/include/c++/v1/list:190:8: note: template is declared here struct __list_node_base ^ Without options listed above all works fine. -- Regards, Serguey. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
On Sep 12, 2013, at 21:47, S.N.Grigoriev serguey-grigor...@yandex.ru wrote: after upgrading to r255423 (make buildworld make buildkernel make installkernel make installworld reboot; make delete-old make delete-old-libs) I cannot build the system with the WITH_GCC=yes and WITH_GNUCXX=yes options in my src.conf. The following error occures: --- libgssapi_krb5.so.10 --- building shared library libgssapi_krb5.so.10 --- gnu/lib__L --- /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:3: error: use of undeclared identifier '_List_node_base' _List_node_base::swap(_List_node_base __x, _List_node_base __y) ^ I just sent a mail to re@ to get approval for a fix for this. In the mean time, please apply the attached patch. -Dimitry fix-libstdc++-build.diff Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
On Fri, Sep 06, 2013 at 09:19:32PM +0100, David Chisnall wrote: As of r255321, we are no longer building gcc or libstdc++ as part of the default install on platforms where clang is cc. I guess I missed where this was discussed. I don't feel we should not ship 10.0 without /usr/bin/g[c+][c+]. It is still very useful for folks to test changes in order to help ensure one doesn't break the build on platforms still using GCC. In the past, we've deprecated for a full release and then remove on the next. This is pretty late in the 10.0 game (now in code freeze) to be making such impactful changes. We have no idea how many 3rd party Makefiles (or other build systems) specify gcc explicitly. 2) Put WITH_GCC=yes and WITH_GNUCXX=yes in your src.conf when you build world. GCC will stay in the base system tree for at least the lifetime of the 10.x release, and possibly longer if it is still being actively used. It will remain used by tinderboxes and make universe for some architectures, so if you commit code without testing with gcc people will know very soon... Requiring folks to keep remembering to add this knob to any new installation will make it harder for developers to test... Compare to the buildworld time impact of Clang, the GCC build is nothing, so why not just have a WITHOUT_GCC knob for those that want nothing more to do with GCC? -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
2013/9/9 David Chisnall thera...@freebsd.org: On 9 Sep 2013, at 14:27, Ulrich Spörlein u...@freebsd.org wrote: Case in point, I only recently switched to clang in base and now the newsbeuter port crashes during startup (yeah, it builds fine). So all I'm asking for now is: how can I override a random port to be built with gcc (either from base or ports, I don't care). And what special considerations need to be done when the port uses C++. Setting USE_GCC=any to build with any gcc, or USE_GCC=yes to build with a gcc from ports (they should do the same thing on a no-gcc-in-base system) For C++ ports, can you check whether the error is from libc++ or clang, by first building libstdc++ from base and then setting CXXFLAGS=-stdlib=libstdc++ and LDFLAGS=-stdlib=libstdc++? This will build it with libstdc++ and if that works then it narrows the issue down. Also, don't forget to report bugs to the port maintainer... root@coyote:/usr/ports/www/newsbeuter# ldd `which newsbeuter` /usr/local/bin/newsbeuter: libthr.so.3 = /lib/libthr.so.3 (0x80093f000) libiconv.so.3 = /usr/lib/libiconv.so.3 (0x800b64000) libintl.so.9 = /usr/local/lib/libintl.so.9 (0x800d65000) libsqlite3.so.8 = /usr/local/lib/libsqlite3.so.8 (0x800f6f000) libcurl.so.7 = /usr/local/lib/libcurl.so.7 (0x80125) libxml2.so.5 = /usr/local/lib/libxml2.so.5 (0x8014ab000) libstfl.so = /usr/local/lib/libstfl.so (0x801825000) libjson.so.0 = /usr/local/lib/libjson.so.0 (0x801a34000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x801c3b000) libm.so.5 = /lib/libm.so.5 (0x801f3b000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x80216) libc.so.7 = /lib/libc.so.7 (0x80236d000) libcrypto.so.7 = /lib/libcrypto.so.7 (0x802705000) libncursesw.so.8 = /lib/libncursesw.so.8 (0x802af) libssl.so.7 = /usr/lib/libssl.so.7 (0x802d45000) libgssapi.so.10 = /usr/lib/libgssapi.so.10 (0x802fae000) libz.so.6 = /lib/libz.so.6 (0x8031b7000) liblzma.so.5 = /usr/lib/liblzma.so.5 (0x8033cc000) So this is already linking to libstdc++ instead of libc++ (has libc++ been made the default on -CURRENT yet?) Anyway, the problem is our libiconv (of course!), as the following works: env LD_LIBRARY_PATH=/usr/local/lib:/usr/lib newsbeuter It'll load the ports version of libiconv first, so the problem is with libiconv in base :( Sorry for barking up the wrong tree, correlation does not imply causation, eh?) Cheers, Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
On Fri, 2013-09-06 at 21:19:32 +0100, David Chisnall wrote: Hi Everyone, As of r255321, we are no longer building gcc or libstdc++ as part of the default install on platforms where clang is cc. If you are using gcc, you have two options: 1) Install one of the lang/gcc* ports (Warner has been working on separating out the patches to our GCC, so these should soon be patched to provide the same features as the one in base) 2) Put WITH_GCC=yes and WITH_GNUCXX=yes in your src.conf when you build world. GCC will stay in the base system tree for at least the lifetime of the 10.x release, and possibly longer if it is still being actively used. It will remain used by tinderboxes and make universe for some architectures, so if you commit code without testing with gcc people will know very soon... Thanks to Warner for all of his recent work on disentangling the toolchain, to all of the people (Roman, Dimitry, Brooks, and others) who worked on getting clang integrated into FreeBSD and to everyone who tested it and filed bug reports. As of today, PowerPC64 joins x86 and ARM as platforms where world+kernel can be successfully built (and work) with clang (although it isn't the default yet and needs more testing), and hopefully other architectures will follow soon. Huge thanks to all of the ports people who have spent the last two weeks working on dealing with the fallout from iconv and ensuring that all of the ports work with clang and libc++. I think over the last week, the number of failing / ignored ports has dropped by about a thousand a day on the no-gcc test box that Bapt has been running, which is a phenomenal achievement. Indeed, thanks to all for their hard work, this is good news overall! To nitpick, however, what has been fixed is that ports build with clang and libc++, no effort can humanely be done to make sure they really *work* as before. Case in point, I only recently switched to clang in base and now the newsbeuter port crashes during startup (yeah, it builds fine). So all I'm asking for now is: how can I override a random port to be built with gcc (either from base or ports, I don't care). And what special considerations need to be done when the port uses C++. Cheers, Uli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
On 9 Sep 2013, at 14:27, Ulrich Spörlein u...@freebsd.org wrote: Case in point, I only recently switched to clang in base and now the newsbeuter port crashes during startup (yeah, it builds fine). So all I'm asking for now is: how can I override a random port to be built with gcc (either from base or ports, I don't care). And what special considerations need to be done when the port uses C++. Setting USE_GCC=any to build with any gcc, or USE_GCC=yes to build with a gcc from ports (they should do the same thing on a no-gcc-in-base system) For C++ ports, can you check whether the error is from libc++ or clang, by first building libstdc++ from base and then setting CXXFLAGS=-stdlib=libstdc++ and LDFLAGS=-stdlib=libstdc++? This will build it with libstdc++ and if that works then it narrows the issue down. Also, don't forget to report bugs to the port maintainer... David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
On Fri, 6 Sep 2013 21:19:32 +0100 David Chisnall thera...@freebsd.org wrote: Hi Everyone, As of r255321, we are no longer building gcc or libstdc++ as part of the default install on platforms where clang is cc. If you are using gcc, you have two options: 1) Install one of the lang/gcc* ports (Warner has been working on separating out the patches to our GCC, so these should soon be patched to provide the same features as the one in base) 2) Put WITH_GCC=yes and WITH_GNUCXX=yes in your src.conf when you build world. GCC will stay in the base system tree for at least the lifetime of the 10.x release, and possibly longer if it is still being actively used. It will remain used by tinderboxes and make universe for some architectures, so if you commit code without testing with gcc people will know very soon... Thanks to Warner for all of his recent work on disentangling the toolchain, to all of the people (Roman, Dimitry, Brooks, and others) who worked on getting clang integrated into FreeBSD and to everyone who tested it and filed bug reports. As of today, PowerPC64 joins x86 and ARM as platforms where world+kernel can be successfully built (and work) with clang (although it isn't the default yet and needs more testing), and hopefully other architectures will follow soon. Huge thanks to all of the ports people who have spent the last two weeks working on dealing with the fallout from iconv and ensuring that all of the ports work with clang and libc++. I think over the last week, the number of failing / ignored ports has dropped by about a thousand a day on the no-gcc test box that Bapt has been running, which is a phenomenal achievement. David Removing the outdated stuff with make delete-old in /usr/src leaves me with some recently touched include files in /usr/include/gcc/4.2: ll /usr/include/gcc/4.2/ total 14 236810 drwxr-xr-x 2 root wheel - 512B 7 Sep 10:50 ./ 235531 drwxr-xr-x 3 root wheel - 512B 3 Nov 2010 ../ 236036 -r--r--r-- 1 root wheel - 1.9k 4 Sep 12:07 __wmmintrin_aes.h 236058 -r--r--r-- 1 root wheel -2k 4 Sep 12:07 __wmmintrin_pclmul.h 235704 -r--r--r-- 1 root wheel - 2.3k 7 Jun 08:55 ammintrin.h 236028 -r--r--r-- 1 root wheel - 1.6k 4 Sep 12:07 wmmintrin.h (sorry for the weird breakup of the line). Regards, Oliver [...] Removing old files (only deletes safe to delete libs) remove /usr/lib/libisc.a? remove /usr/lib/libisc.so? remove /usr/lib/libisc_p.a? remove /usr/include/isc/assertions.h? remove /usr/include/isc/heap.h? remove /usr/include/isc/list.h? remove /usr/bin/g++? y remove /usr/bin/gcc? y remove /usr/bin/gcov? y remove /usr/bin/gcpp? y remove /usr/include/gcc/4.2/emmintrin.h? y remove /usr/include/gcc/4.2/mm_malloc.h? y remove /usr/include/gcc/4.2/mmintrin.h? y remove /usr/include/gcc/4.2/pmmintrin.h? y remove /usr/include/gcc/4.2/tmmintrin.h? y remove /usr/include/gcc/4.2/xmmintrin.h? y remove /usr/include/gcc/4.2/mm3dnow.h? y remove /usr/libexec/cc1? y remove /usr/libexec/cc1plus? y remove /usr/share/info/cpp.info.gz? y remove /usr/share/info/cppinternals.info.gz? y remove /usr/share/info/gcc.info.gz? y remove /usr/share/info/gccint.info.gz? y remove /usr/share/man/man1/g++.1.gz? y remove /usr/share/man/man1/gcc.1.gz? y remove /usr/share/man/man1/gcov.1.gz? y remove /usr/share/man/man1/gcpp.1.gz? y remove /usr/share/man/cat1/gcc.1.gz? y remove /usr/share/man/cat1/g++.1.gz? y remove /usr/share/man/cat1/gcov.1.gz? y remove /usr/share/man/cat1/gcpp.1.gz? y Old files removed Removing old directories rmdir: /usr/include/gcc/4.2: Directory not empty rmdir: /usr/include/gcc: Directory not empty Old directories removed To remove old libraries run 'make delete-old-libs'. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HEADS UP: No gcc by default in -HEAD on platforms where clang is cc
Hi Everyone, As of r255321, we are no longer building gcc or libstdc++ as part of the default install on platforms where clang is cc. If you are using gcc, you have two options: 1) Install one of the lang/gcc* ports (Warner has been working on separating out the patches to our GCC, so these should soon be patched to provide the same features as the one in base) 2) Put WITH_GCC=yes and WITH_GNUCXX=yes in your src.conf when you build world. GCC will stay in the base system tree for at least the lifetime of the 10.x release, and possibly longer if it is still being actively used. It will remain used by tinderboxes and make universe for some architectures, so if you commit code without testing with gcc people will know very soon... Thanks to Warner for all of his recent work on disentangling the toolchain, to all of the people (Roman, Dimitry, Brooks, and others) who worked on getting clang integrated into FreeBSD and to everyone who tested it and filed bug reports. As of today, PowerPC64 joins x86 and ARM as platforms where world+kernel can be successfully built (and work) with clang (although it isn't the default yet and needs more testing), and hopefully other architectures will follow soon. Huge thanks to all of the ports people who have spent the last two weeks working on dealing with the fallout from iconv and ensuring that all of the ports work with clang and libc++. I think over the last week, the number of failing / ignored ports has dropped by about a thousand a day on the no-gcc test box that Bapt has been running, which is a phenomenal achievement. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
