[MacPorts] #38814: libstdcxx subport's linkage on libgcc_eh.a incorrectly causes the usage of two different unwinders
MacPorts
noreply at macports.org
Mon Apr 15 07:26:55 PDT 2013
#38814: libstdcxx subport's linkage on libgcc_eh.a incorrectly causes the usage of
two different unwinders
-----------------------+--------------------------------
Reporter: howarth@… | Owner: macports-tickets@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.1.3
Keywords: | Port: libstdcxx
-----------------------+--------------------------------
The current libstdcxx subport links in libgcc_eh.a. This causes the FSF
gcc unwinder to be used within the libstdc++ dynamic lib code but the
system unwinder in other code generated by the g++-mp-4.x compilers. This
is forbidden behavior as only a single unwinder should be in use and this
should always be the system unwinder. In a perfect world, the static
libgcc_eh would be rewritten to use the same code used for the
compatibility unwinder in libSystem or the compiler-rt compact unwinder.
Given the current situation, the best solution possible is to avoid the
hack of linking in -static-libgcc for the libstdc++ shared library but
instead add the libgcc*dylib files to the libstdcxx subport so that they
are always available for the libstdc++ shared lib from FSF gcc. These
libgcc_ext stubs have been carefully crafted to only provide those symbols
not defined in libSystem on darwin and will insure a single unwinder (the
system one) is always in use. Note that the spec generated by -static-gcc
always passes libstdc++.a to the linker when the g++ compiler is used.
This behavior is broken in MacPorts due to the absence of libstdc++.a in
the packaged gcc4x. If you are worried about that feature, each gcc4x
package should also have its own libstdc++.a retained.
--
Ticket URL: <https://trac.macports.org/ticket/38814>
MacPorts <http://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list