#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