Opened 11 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)

Portfile.diff (2.7 KB) - added by howarth@… 11 years ago.
Portfile diff to update to 4.7.4 and support the move of libgcc*dylib files to libstdcxx in gcc48
libstdc++_nanosleep.patch (1.1 KB) - added by howarth@… 11 years ago.
backport of proper nanosleep fix for threads in libstdc++
test.cc (328 bytes) - added by howarth@… 11 years ago.
testcase that exposes use of two unwinders in current packaging

Download all attachments as: .zip

Change History (9)

Changed 11 years ago by howarth@…

Attachment: Portfile.diff added

Portfile diff to update to 4.7.4 and support the move of libgcc*dylib files to libstdcxx in gcc48

Changed 11 years ago by howarth@…

Attachment: libstdc++_nanosleep.patch added

backport of proper nanosleep fix for threads in libstdc++

comment:1 Changed 11 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 11 years ago by mf2k (Frank Schima)

Cc: jeremyhu@… added
Version: 2.1.3

Changed 11 years ago by howarth@…

Attachment: test.cc added

testcase that exposes use of two unwinders in current packaging

comment:3 Changed 11 years ago by howarth@…

Shouldn't all gcc4x packages which have the same soversion for libstdc++ be using the libstdcxx subport?

comment:4 in reply to:  3 ; Changed 11 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 in reply to:  4 Changed 11 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: newclosed

This is a dupe of #38814

As mentioned there, your segfault is because of mixing emutls implementations, not because of unwinder issues.

Note: See TracTickets for help on using tickets.