Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 444678

Summary: sys-devel/gcc-4.7.2 -- build fails on G/FBSD 9.1 with USE=cxx
Product: Gentoo/Alt Reporter: Yuta SATOH <nigoro.dev>
Component: FreeBSDAssignee: Gentoo/BSD Team <bsd+disabled>
Status: RESOLVED UPSTREAM    
Severity: normal CC: daniel, genzilla, toolchain
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: FreeBSD   
URL: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
See Also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51776
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 462580    
Attachments: sample patch for toolchain.eclass
files/freebsd-sources-9.1-cdefs.h-gcc47.patch
patch for freebsd-lib-9.1.ebuild
patch for freebsd-sources-9.1-r1.ebuild
FYI, include-fixed/sys/cdefs.h diff.

Description Yuta SATOH 2012-11-25 13:07:51 UTC
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
Comment 1 Yuta SATOH 2012-11-25 13:10:19 UTC
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
Comment 2 Yuta SATOH 2013-03-06 11:11:45 UTC
gcc-4.7.2 has been unmasked.
Change the priority, adding toolchain to CC.
Comment 3 Yuta SATOH 2013-03-06 11:15:35 UTC
Created attachment 341102 [details, diff]
sample patch for toolchain.eclass

I have confirmed that installation is passing by keep include-fixed/sys/cdefs.h.
Comment 4 Ryan Hill (RETIRED) gentoo-dev 2013-05-15 03:14:50 UTC
That's kinda nasty.  I take it you can't patch the FBSD headers?
Comment 5 Alexis Ballier gentoo-dev 2013-05-15 20:13:34 UTC
(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
Comment 6 Ryan Hill (RETIRED) gentoo-dev 2013-05-16 01:58:11 UTC
Yes I understand the patch.  I don't think we should start installing fixincluded headers on a case-by-case basis.
Comment 7 Yuta SATOH 2013-05-16 11:29:30 UTC
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.
Comment 8 Yuta SATOH 2013-05-16 11:30:21 UTC
Created attachment 348462 [details, diff]
patch for freebsd-lib-9.1.ebuild
Comment 9 Yuta SATOH 2013-05-16 11:30:50 UTC
Created attachment 348464 [details, diff]
patch for freebsd-sources-9.1-r1.ebuild
Comment 10 Yuta SATOH 2013-05-16 11:33:17 UTC
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
Comment 11 Alexis Ballier gentoo-dev 2013-05-16 17:01:40 UTC
(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.
Comment 12 Ryan Hill (RETIRED) gentoo-dev 2013-05-17 05:22:06 UTC
(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.
Comment 13 Alexis Ballier gentoo-dev 2013-05-20 10:55:20 UTC
(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
Comment 14 SpanKY gentoo-dev 2013-05-22 04:57:26 UTC
(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.
Comment 15 Alexis Ballier gentoo-dev 2013-05-22 13:39:42 UTC
(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.
Comment 16 SpanKY gentoo-dev 2013-05-22 16:09:49 UTC
(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
Comment 17 Alexis Ballier gentoo-dev 2013-05-22 16:41:42 UTC
(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.
Comment 18 SpanKY gentoo-dev 2013-05-22 19:56:36 UTC
(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.
Comment 19 Alexis Ballier gentoo-dev 2013-05-22 20:10:57 UTC
(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.
Comment 20 SpanKY gentoo-dev 2013-05-23 05:18:38 UTC
(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.