Opened 12 years ago
Closed 11 years ago
#38778 closed update (duplicate)
gcc46 update to support libgcc*dylib move to libstdcxx in gcc48
Reported by: | howarth@… | Owned by: | mww@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | haspatch | Cc: | jeremyhu (Jeremy Huddleston Sequoia) |
Port: | gcc46 |
Description
The attached packaging removes the libstdcxx subport from gcc46 since gcc48 now contains it as well as implementing the changes to support the move of the libgcc*dylib files into the libstdcxx subport Also added patch to backport the nanosleep support for threads in c++11. The packaging is based on the new 4.7.4 release from upstream.
Attachments (3)
Change History (9)
Changed 12 years ago by howarth@…
Attachment: | Portfile.diff added |
---|
Changed 12 years ago by howarth@…
Attachment: | libstdc++_nanosleep.patch added |
---|
backport of proper nanosleep fix for threads in libstdc++
comment:1 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | haspatch added |
---|---|
Owner: | changed from macports-tickets@… to mww@… |
This patch is for the gcc46 update to 4.6.4 and does not deal with a libstdcxx subport, since none exists in the gcc46 portfile. (It's in the gcc47 portfile and the ticket for that is #38774.)
comment:2 Changed 12 years ago by mf2k (Frank Schima)
Cc: | jeremyhu@… added |
---|---|
Version: | 2.1.3 |
Changed 12 years ago by howarth@…
testcase that exposes use of two unwinders in current packaging
comment:3 follow-up: 4 Changed 12 years ago by howarth@…
Shouldn't all gcc4x packages which have the same soversion for libstdc++ be using the libstdcxx subport?
comment:4 follow-up: 5 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to howarth@…:
Shouldn't all gcc4x packages which have the same soversion for libstdc++ be using the libstdcxx subport?
Yes, they do. That was the whole point of the process.
testcase that exposes use of two unwinders in current packaging
If libstdc++.dylib actually is using multiple unwinders (I still am not convinced of that), please open a ticket to deal with that issue in libstdc++.dylib. Discussion of that issue is quite intricate and should not be spread out over ~5 different trouble tickets as you are doing.
comment:5 Changed 12 years ago by howarth@…
Replying to jeremyhu@…:
Replying to howarth@…:
Shouldn't all gcc4x packages which have the same soversion for libstdc++ be using the libstdcxx subport?
Yes, they do. That was the whole point of the process.
testcase that exposes use of two unwinders in current packaging
If libstdc++.dylib actually is using multiple unwinders (I still am not convinced of that), please open a ticket to deal with that issue in libstdc++.dylib. Discussion of that issue is quite intricate and should not be spread out over ~5 different trouble tickets as you are doing.
ticket:38814 covers this issue. If you insist, I can open up a radar using the failing test.cc testcase built with your current gcc48/libstdcxx which segfaults due to the mix unwinders and ask NIck walk it through a debug libSystem unwinder at Apple to prove this is the case.
comment:6 Changed 11 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → duplicate |
---|---|
Status: | new → closed |
This is a dupe of #38814
As mentioned there, your segfault is because of mixing emutls implementations, not because of unwinder issues.
Portfile diff to update to 4.7.4 and support the move of libgcc*dylib files to libstdcxx in gcc48