The following message is displayed and fails to compile on G/FBSD 9.1. gmake[4]: Entering directory `/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libitm' /bin/sh ./libtool --tag=CXX --mode=compile /var/tmp/portage/sys-devel/gcc-4.7.2/work/build/./gcc/g++ -B/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/./gcc/ -nostdinc++ -nostdinc++ -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libstdc++-v3/include/x86_64-gentoo-freebsd9.1 -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libstdc++-v3/libsupc++ -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libstdc++-v3/include/backward -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libstdc++-v3/testsuite/util -L/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libstdc++-v3/src/.libs -B/usr/x86_64-gentoo-freebsd9.1/bin/ -B/usr/x86_64-gentoo-freebsd9.1/lib/ -isystem /usr/x86_64-gentoo-freebsd9.1/include -isystem /usr/x86_64-gentoo-freebsd9.1/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/config/x86 -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/config/posix -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/config/generic -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm -Wall -Werror -Wc,-pthread -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -MT aatree.lo -MD -MP -MF .deps/aatree.Tpo -c -o aatree.lo /var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/aatree.cc libtool: compile: /var/tmp/portage/sys-devel/gcc-4.7.2/work/build/./gcc/g++ -B/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/./gcc/ -nostdinc++ -nostdinc++ -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libstdc++-v3/include/x86_64-gentoo-freebsd9.1 -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libstdc++-v3/libsupc++ -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libstdc++-v3/include/backward -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libstdc++-v3/testsuite/util -L/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libstdc++-v3/src/.libs -B/usr/x86_64-gentoo-freebsd9.1/bin/ -B/usr/x86_64-gentoo-freebsd9.1/lib/ -isystem /usr/x86_64-gentoo-freebsd9.1/include -isystem /usr/x86_64-gentoo-freebsd9.1/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/config/x86 -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/config/posix -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/config/generic -I/var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm -Wall -pthread -Werror -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -MT aatree.lo -MD -MP -MF .deps/aatree.Tpo -c /var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/aatree.cc -fPIC -DPIC -o .libs/aatree.o In file included from /var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/libitm_i.h:36:0, from /var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/aatree.cc:28: /usr/include/stdlib.h:82:1: error: expected unqualified-id before '[' token /usr/include/stdlib.h:92:1: error: expected unqualified-id before '[' token /usr/include/stdlib.h:151:1: error: expected unqualified-id before '[' token /usr/include/stdlib.h:158:1: error: expected unqualified-id before '[' token In file included from /var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/libitm_i.h:86:0, from /var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/aatree.cc:28: /var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/stmlock.h: In function 'GTM::gtm_version GTM::gtm_inc_clock()': /var/tmp/portage/sys-devel/gcc-4.7.2/work/gcc-4.7.2/libitm/stmlock.h:115:12: error: 'abort' was not declared in this scope gmake[4]: *** [aatree.lo] Error 1 gmake[4]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libitm' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libitm' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.2/work/build/x86_64-gentoo-freebsd9.1/libitm' gmake[1]: *** [all-target-libitm] Error 2 gmake[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.7.2/work/build' gmake: *** [all] Error 2
FYI, I found an email about this issue from the mailing list of FreeBSD. http://lists.freebsd.org/pipermail/svn-src-head/2011-December/032067.html
gcc-4.7.2 has been unmasked. Change the priority, adding toolchain to CC.
Created attachment 341102 [details, diff] sample patch for toolchain.eclass I have confirmed that installation is passing by keep include-fixed/sys/cdefs.h.
That's kinda nasty. I take it you can't patch the FBSD headers?
(In reply to comment #4) > That's kinda nasty. I take it you can't patch the FBSD headers? we can patch them when it makes sense, here it does not. see $URL , and also http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=183096
Yes I understand the patch. I don't think we should start installing fixincluded headers on a case-by-case basis.
Created attachment 348460 [details, diff] files/freebsd-sources-9.1-cdefs.h-gcc47.patch (In reply to comment #6) > Yes I understand the patch. I don't think we should start installing > fixincluded headers on a case-by-case basis. I'll attach the sample patch for header file of FreeBSD.
Created attachment 348462 [details, diff] patch for freebsd-lib-9.1.ebuild
Created attachment 348464 [details, diff] patch for freebsd-sources-9.1-r1.ebuild
Created attachment 348466 [details] FYI, include-fixed/sys/cdefs.h diff. diff -u /usr/include/sys/cdefs.h /usr/lib/gcc/x86_64-gentoo-freebsd9.0/4.7.2/include-fixed/sys/cdefs.h
(In reply to comment #6) > Yes I understand the patch. I don't think we should start installing > fixincluded headers on a case-by-case basis. I don't think we should patch system headers because gcc claims to support c++11 but supports only a subset of it. The best solution is IMHO to add [[noreturn]] support to gcc. I have not tested but it seems 4.8 adds support for it. If it can be backported to 4.7 that'd be great, if not we can simply unkeyword 4.7 and move on when 4.8 gets unmasked.
(In reply to comment #11) > I don't think we should patch system headers because gcc claims to support > c++11 but supports only a subset of it. I don't think any compiler completely supports any given standard. Just some support a larger subset than others. ;) > The best solution is IMHO to add [[noreturn]] support to gcc. I have not > tested but it seems 4.8 adds support for it. If it can be backported to 4.7 > that'd be great, if not we can simply unkeyword 4.7 and move on when 4.8 > gets unmasked. Correct, generalized attributes are in 4.8, but I don't think a backport is possible.
(In reply to comment #12) > (In reply to comment #11) > > I don't think we should patch system headers because gcc claims to support > > c++11 but supports only a subset of it. > > I don't think any compiler completely supports any given standard. Just > some > support a larger subset than others. ;) I seriously hope gcc supports ANSI C, ISO C++, etc. and if it doesn't shouldn't claim it does :=) > > The best solution is IMHO to add [[noreturn]] support to gcc. I have not > > tested but it seems 4.8 adds support for it. If it can be backported to 4.7 > > that'd be great, if not we can simply unkeyword 4.7 and move on when 4.8 > > gets unmasked. > > Correct, generalized attributes are in 4.8, but I don't think a backport is > possible. + 20 May 2013; Alexis Ballier <aballier@gentoo.org> gcc-4.7.0.ebuild, + gcc-4.7.1.ebuild, gcc-4.7.2-r1.ebuild, gcc-4.7.3.ebuild: + drop fbsd keywords on gcc 4.7: bug #444678; gcc 4.8 is fine so we can move on + with that version when it gets unmasked. + please don't forget to restore fbsd keywords on 4.8 when you'll add them
(In reply to comment #13) gcc has always been pretty clear in what it does/does not support: http://gcc.gnu.org/onlinedocs/gcc/Standards.html this is nothing new nor gcc specific as Ryan indicated ... as new standards come out, gcc slowly fills out support for the various parts with each release. doing all or nothing releases when it comes to specs makes no sense. if FreeBSD checks merely for the existence of a flag instead of a more directed feature test, then that's the FreeBSD system being naive (or at least, they don't care since they have a locked base system and are looking to migrate to clang). i also agree with Ryan that we should not be special casing fixed-headers. dekeywording makes the most sense.
(In reply to comment #14) if for you testing for a flag that means "support for a given standard" is naive then we have a different definition of standard and might as well not trust anything and autotoolize every function/feature used. anyway, there's no point in arguing anymore since it is fixed in 4.8 without hack on any side; also, we should seriously be moving g/fbsd to clang too for various other more annoying reasons.
(In reply to comment #15) yes, it is naïve, and anyone who has ever seriously looked at any compiler and its standard support would be familiar with this. clang is no different: http://clang.llvm.org/cxx_status.html the only difference is that FreeBSD is pinning itself to clang's behavior instead of the gcc version they have integrated
(In reply to comment #16) its not more naive than believing one can make a feature check for the definition of a function in a system header. it has to be #if'ed, and the standard version the compiler claims to support seems to be the best choice here... gcc was fine until it started to claim c++11 support without having support for the features used by freebsd; those gcc versions correspond to the 4.7 branch without fixincluded headers which is likely to be a gentooism. fbsd integrated version is gcc 4.2.1 in case you didn't know and gcc from ports probably installs the fixincluded cdefs header, so there is no problem and no pinning to clang here.
(In reply to comment #17) we aren't talking about a function, we're talking about an attribute. but that part is irrelevant, not what i was saying in the first place, and is still fairly trivial to do. glibc provides a __GNUC_PREREQ macro to make manual disabling for known versions dirt simple. i'm guessing you're not really aware of what fixincludes is, or what other distros do. fairly certain other distros also strip out fixincludes just like Gentoo does (Debian & Fedora certainly seem to which covers their derivatives too). fbsd pinned themselves to 4.2 (which doesn't support any C++11 and hence fixed cdefs.h makes no sense either) because newer versions cut over to GPL-3 for licensing and they wanted to avoid that. which means fbsd is pinning themselves to the clang codebase since that is the only C++11 compiler they're actively using.
(In reply to comment #18) if the attribute was not used in a function definition this would be a non-issue; but yes, they're pinning themselves to clang in that sense and also in the sense that gcc is relegated to a secondary compiler for which it is much more debatable whether the system has to workaround compiler deficiencies.
(In reply to comment #19) sure, they've picked clang and so they write code that is compatible with that which allows them to skip workarounds for others. i doubt too many people use gcc anymore on FreeBSD except for crazies like us.
