Opened 10 years ago

Closed 21 months ago

#43869 closed defect (wontfix)

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.3.0
Keywords: Cc: jeremyhu (Jeremy Huddleston Sequoia), mfeiri, cooljeanius (Eric Gallager), larryv (Lawrence Velázquez), Dave-Allured (Dave Allured)
Port: libgcc

Description

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)

Attachments (14)

main.log.bz2 (115.3 KB) - added by ryandesign (Ryan Carsten Schmidt) 10 years ago.
libgcc-4.9.2.main.log.bz2 (117.4 KB) - added by ryandesign (Ryan Carsten Schmidt) 9 years ago.
libgcc-devel-5-20150111.main.log.bz2 (187.6 KB) - added by ryandesign (Ryan Carsten Schmidt) 9 years ago.
libgcc-4.9.2-preprocessed-source (143.7 KB) - added by ryandesign (Ryan Carsten Schmidt) 9 years ago.
libgcc-devel-5-20150111-preprocessed-source (166.2 KB) - added by ryandesign (Ryan Carsten Schmidt) 9 years ago.
larryv.eh_alloc.cpp (144.1 KB) - added by larryv (Lawrence Velázquez) 9 years ago.
preprocessed eh_alloc.cc from gcc5
eh_alloc.cpp.diff (64.9 KB) - added by larryv (Lawrence Velázquez) 9 years ago.
diff between our preprocessed source
larryv.libgcc-devel.main.log (26.7 MB) - added by larryv (Lawrence Velázquez) 9 years ago.
single-threaded log from libgcc-devel destroot
libgcc-4.9.2-preprocessed-source.2 (143.9 KB) - added by ryandesign (Ryan Carsten Schmidt) 9 years ago.
libgcc-devel-5-20150111-preprocessed-source.2 (166.2 KB) - added by ryandesign (Ryan Carsten Schmidt) 9 years ago.
libgcc.sh (2.3 KB) - added by ryandesign (Ryan Carsten Schmidt) 9 years ago.
libgcc-devel.sh (2.4 KB) - added by ryandesign (Ryan Carsten Schmidt) 9 years ago.
xgcc-eh_alloc.cc-verbose.txt (11.4 KB) - added by larryv (Lawrence Velázquez) 9 years ago.
verbose xgcc output with CPATH, without -isystem
xgcc-eh_alloc.cc-verbose-isysroot.txt (17.6 KB) - added by larryv (Lawrence Velázquez) 9 years ago.
verbose xgcc output with CPATH, with -isystem

Change History (52)

Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: main.log.bz2 added

comment:1 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: mfeiri@… added

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".

comment:2 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: newclosed

comment:4 Changed 10 years ago by larryv (Lawrence Velázquez)

Cc: larryv@… added

Cc Me!

comment:5 Changed 9 years ago by 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.

comment:6 in reply to:  5 Changed 9 years ago by 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.

comment:7 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: closedreopened

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.

comment:8 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by 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.

Last edited 9 years ago by jeremyhu (Jeremy Huddleston Sequoia) (previous) (diff)

comment:10 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: reopenedclosed

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

comment:11 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

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

comment:12 Changed 9 years ago by 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.

comment:13 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: libgcc-4.9.2.main.log.bz2 added

Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

comment:14 in reply to:  13 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to jeremyhu@…:

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

Ok, it's attached.

comment:15 Changed 9 years ago by 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/.

Changed 9 years ago by larryv (Lawrence Velázquez)

Attachment: larryv.eh_alloc.cpp added

preprocessed eh_alloc.cc from gcc5

comment:16 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

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

Changed 9 years ago by larryv (Lawrence Velázquez)

Attachment: eh_alloc.cpp.diff added

diff between our preprocessed source

comment:17 Changed 9 years ago by larryv (Lawrence Velázquez)

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

Changed 9 years ago by larryv (Lawrence Velázquez)

single-threaded log from libgcc-devel destroot

comment:18 Changed 9 years ago by 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).

comment:19 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Ryan, your preprocessed source clearly has _Unwind_Ptr

2046	# 46 "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/build/x86_64-apple-darwin14/libstdc++-v3/include/cstddef" 2 3
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/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/build/gcc/include/unwind.h" 1 3 4
2049	# 37 "/opt/local/var/macports/build/_Users_rschmidt_macports_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
}}}
Last edited 9 years ago by jeremyhu (Jeremy Huddleston Sequoia) (previous) (diff)

comment:20 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)

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

comment:21 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

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

Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: libgcc.sh added

Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Attachment: libgcc-devel.sh added

comment:22 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

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

comment:23 Changed 9 years ago by 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
Last edited 9 years ago by jeremyhu (Jeremy Huddleston Sequoia) (previous) (diff)

comment:24 Changed 9 years ago by 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.

comment:25 in reply to:  23 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to jeremyhu@…:

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

Yes!

comment:26 in reply to:  24 Changed 9 years ago by 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.

comment:27 Changed 9 years ago by 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).

Changed 9 years ago by larryv (Lawrence Velázquez)

verbose xgcc output with CPATH, without -isystem

Changed 9 years ago by larryv (Lawrence Velázquez)

verbose xgcc output with CPATH, with -isystem

comment:28 in reply to:  27 Changed 9 years ago by 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.

comment:29 Changed 9 years ago by 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.

comment:30 Changed 9 years ago by mfeiri

Resolution: fixed
Status: closedreopened

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.

comment:31 Changed 9 years ago by 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.

comment:32 in reply to:  31 ; Changed 9 years ago by 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.

comment:33 in reply to:  32 ; Changed 9 years ago by 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?

comment:34 in reply to:  33 Changed 9 years ago by larryv (Lawrence Velázquez)

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

comment:35 Changed 7 years ago by kurthindenburg (Kurt Hindenburg)

Owner: changed from mww@… to macports-tickets@…
Status: reopenedassigned

comment:36 Changed 5 years ago by kencu (Ken)

has duplicate 57198

comment:37 Changed 5 years ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:38 Changed 21 months ago by cjones051073 (Chris Jones)

Resolution: wontfix
Status: assignedclosed

closing as no longer relevant to current version.

Note: See TracTickets for help on using tickets.