libgcc @4.8.2_1: error: '_Unwind_Ptr' does not name a type

[ryandesign (Ryan Carsten Schmidt)]

libgcc @4.8.2_0 is installed but libgcc @4.8.2_1 fails to build for me with:

In file included from /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/eh_alloc.cc:35:0:
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:92:3: error: '_Unwind_Ptr' does not name a type
   _Unwind_Ptr catchTemp;
   ^
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:141:3: error: '_Unwind_Ptr' does not name a type
   _Unwind_Ptr catchTemp;
   ^
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:315:7: error: '_Unwind_Exception_Class' does not name a type
 const _Unwind_Exception_Class __gxx_primary_exception_class
       ^
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:327:7: error: '_Unwind_Exception_Class' does not name a type
 const _Unwind_Exception_Class __gxx_dependent_exception_class
       ^
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:338:26: error: '__cxxabiv1::__is_gxx_exception_class' declared as an 'inline' variable
 __is_gxx_exception_class(_Unwind_Exception_Class c)
                          ^
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:338:26: error: '_Unwind_Exception_Class' was not declared in this scope
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:339:1: error: expected ',' or ';' before '{' token
 {
 ^
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:347:26: error: '__cxxabiv1::__is_dependent_exception' declared as an 'inline' variable
 __is_dependent_exception(_Unwind_Exception_Class c)
                          ^
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:347:26: error: '_Unwind_Exception_Class' was not declared in this scope
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:348:1: error: expected ',' or ';' before '{' token
 {
 ^
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:358:28: error: '_Unwind_Exception_Class' has not been declared
      (int, _Unwind_Action, _Unwind_Exception_Class,
                            ^
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc48/libgcc/work/gcc-4.8.2/libstdc++-v3/libsupc++/unwind-cxx.h:363:28: error: '_Unwind_Exception_Class' has not been declared
      (int, _Unwind_Action, _Unwind_Exception_Class,
                            ^

OS X 10.9.3, Xcode 5.1.1, Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)

[ryandesign (Ryan Carsten Schmidt)]

This was caused by having libunwind-headers @35.1_1 installed an active. Until #42500 is completed libgcc should declare that it "conflicts_build libunwind-headers".

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

r125551

[larryv (Lawrence Velázquez)]

Cc Me!

[mfeiri]

Didn't this cause hard build/update errors for anyone who ever installed gcc in macports before r125552? Anyway, while #42500 is still not entirely resolved, the destroot location of libunwind-headers was changed in r127042. Removed the explicit build conflict in r127045.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mfeiri@…:

Didn't this cause hard build/update errors for anyone who ever installed gcc in macports before r125552?

Presumably yes, for those users building from source; most users would have received binaries from the packages server.

[jeremyhu (Jeremy Huddleston Sequoia)]

Reopening to fix this in gcc ports. It sounds to me like the issue is that when libstdc++ was building, it was preferring headers for the system unwinder instead of its own. I suspect just reordering -I... on the command line would fix the issue.

[jeremyhu (Jeremy Huddleston Sequoia)]

libunwind-headers were moved back to ${prefix} due to the report in #46521. I'll see if I can figure out a simple fix for this issue.

[jeremyhu (Jeremy Huddleston Sequoia)]

libgcc from gcc-4.9.2 built fine for me with current versions of libunwind-headers installed directly to ${prefix}. I'll try installing older gcc versions to see where this is a problem.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, I suspect upstream gcc fixed this at some point. Great!

[ryandesign (Ryan Carsten Schmidt)]

This problem still occurs with the latest gcc5 snapshot from January 11th.

[larryv (Lawrence Velázquez)]

Blegh, I can’t reproduce this on Yosemite with libunwind-headers @3.5.0_7 and either libgcc @4.9.2_1 or libgcc-devel @5-20150111.

[jeremyhu (Jeremy Huddleston Sequoia)]

Ryan, can you attach the preprocessed source for the failing compilation?

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

Ryan, can you attach the preprocessed source for the failing compilation?

Ok, it's attached.

[larryv (Lawrence Velázquez)]

The only real difference I can see between your compilation command and mine is that yours has this:

-isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk

I guess you’re building +universal?

Consequently, our preprocessed source looks almost identical, except all your system headers are coming from the OS X SDK and not from /usr/include/.

[larryv (Lawrence Velázquez)]

preprocessed eh_alloc.cc from gcc5

[ryandesign (Ryan Carsten Schmidt)]

Ah. Not universal for this test, but my base is patched to always include the SDK as per #41783.

[larryv (Lawrence Velázquez)]

diff between our preprocessed source

[larryv (Lawrence Velázquez)]

And here​ is the diff, with our build paths normalized.

[larryv (Lawrence Velázquez)]

single-threaded log from libgcc-devel destroot

[ryandesign (Ryan Carsten Schmidt)]

In case relevant: I am running a beta version of OS X 10.10.2 (14C94b), but a stable version of Xcode 6.1.1 (6A2008a).

[jeremyhu (Jeremy Huddleston Sequoia)]

Ryan, your preprocessed source clearly has _Unwind_Ptr

2049	# 37 "/opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/build/gcc/include/unwind.h" 3 4
...
2066	typedef unsigned _Unwind_Ptr __attribute__((__mode__(__pointer__)));}}}

It also compiles just fine with:

cat ~/Downloads/libgcc-devel-5-20150111-preprocessed-source | /usr/bin/clang++ -x c++ -c - -o /tmp/test.o

edit: I accidentally quoted larryv's source, but I really did compile Ryan's and the information applies to ryan's modulo worksrcpath.

[jeremyhu (Jeremy Huddleston Sequoia)]

Did you set CPATH='/opt/local/include' when generating the preprocessed source?

[ryandesign (Ryan Carsten Schmidt)]

No, I didn't set any environment variables. I can try again setting the ones MacPorts sets.

[ryandesign (Ryan Carsten Schmidt)]

Ok, new versions of pre-processed source attached, along with the scripts I used to generate them.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yep. And if you drop your -isysroot, does it work? I wonder if this is a bug with -isysroot in gcc.

2047	# 36 "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20150111/libstdc++-v3/libsupc++/unwind-cxx.h" 2
2048	# 1 "/opt/local/include/unwind.h" 1

[jeremyhu (Jeremy Huddleston Sequoia)]

So it looks like from the command line, we're expecting to find unwind.h because of the:

-B/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/build/./gcc

but CPATH=/opt/local/include is taking precedence over that in Ryan's case but not in mine or Larry's.

I'm having trouble figuring out a reduced case.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

And if you drop your -isysroot, does it work?

Yes!

[larryv (Lawrence Velázquez)]

Replying to jeremyhu@…:

but CPATH=/opt/local/include is taking precedence over that in Ryan's case but not in mine or Larry's.

Ah, I didn’t set CPATH when generating my preprocessed source. It fails for me too when I set CPATH, but works after removing -isysroot.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yeah, so that seems to point towards the built xgcc having a bug with its search path ordering. It would be nice to see the output with you tacking on '-v' to gcc (no need to get preprocessed source, just the -v bits) to see what xgcc is using for its header search path in the two cases (with vs without -isysroot while CPATH is set).

[larryv (Lawrence Velázquez)]

verbose xgcc output with CPATH, without -isystem

[larryv (Lawrence Velázquez)]

verbose xgcc output with CPATH, with -isystem

[larryv (Lawrence Velázquez)]

Header search path with CPATH but without -isystem (see also full verbose output​):

#include "..." search starts here:
#include <...> search starts here:
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/gcc-5-20150111/libstdc++-v3/../libgcc
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/build/x86_64-apple-darwin14/libstdc++-v3/include/x86_64-apple-darwin14
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/build/x86_64-apple-darwin14/libstdc++-v3/include
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/gcc-5-20150111/libstdc++-v3/libsupc++
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/build/./gcc/include
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/build/./gcc/include-fixed
 /opt/local/include
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.

Header search path with both CPATH and -isystem (see also full verbose output):

#include "..." search starts here:
#include <...> search starts here:
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/gcc-5-20150111/libstdc++-v3/../libgcc
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/build/x86_64-apple-darwin14/libstdc++-v3/include/x86_64-apple-darwin14
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/build/x86_64-apple-darwin14/libstdc++-v3/include
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/gcc-5-20150111/libstdc++-v3/libsupc++
 /opt/local/include
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/build/./gcc/include
 /opt/local/var/macports/build/_Users_larryv_Projects_MacPorts_git-svn_trunk_dports_lang_gcc5/libgcc-devel/work/build/./gcc/include-fixed
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks
End of search list.

The CPATH directory and gcc/include{,-fixed} are getting swapped.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yep:

With -isysroot, they swap the order of CPATH and -B searching. With -isysroot, CPATH is before -B. Without -isysroot, -B is before CPATH.

This will require a code change within gcc to fix, and I can't do that as it's GPLv3, but the information here should be enough to get the ball rolling upstream. Larry or Ryan, can you file a bug upstream and note the URL here? Once a fix is ready, we can hopefully cherry-pick that into the gcc ports.

[mfeiri]

So, "upstream gcc fixed this" turned out to be wrong and instead this "will require a code change within gcc to fix". I think that means this ticket is still open. Since the solution in r127042 was reverted, we should reinstate r125551.

[jeremyhu (Jeremy Huddleston Sequoia)]

No. This only impacts people using who are testing #41783. This doesn't impact anyone by default. Thus there is no reason to do r125551 as you can see the buildbots are perfectly happy.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jeremyhu@…:

No. This only impacts people using who are testing #41783. This doesn't impact anyone by default.

Agreed.

Thus there is no reason to do r125551 as you can see the buildbots are perfectly happy.

Well, the buildbots are happy because they do not have libunwind-headers installed when they build gcc.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ryandesign@…:

Replying to jeremyhu@…:

No. This only impacts people using who are testing #41783. This doesn't impact anyone by default.

Agreed.

Thus there is no reason to do r125551 as you can see the buildbots are perfectly happy.

Well, the buildbots are happy because they do not have libunwind-headers installed when they build gcc.

Ah, yes. Of course. In any event, they would probably still be ok even if libunwind-headers was installed =)

Any luck poking upstream gcc to fix their bug?

[larryv (Lawrence Velázquez)]

I’ll do it soon, unless someone else already has.

[kencu (Ken)]

has duplicate 57198

[cjones051073 (Chris Jones)]

closing as no longer relevant to current version.