#38814: libstdcxx subport's linkage on libgcc_eh.a incorrectly causes the usage of two different unwinders ------------------------+------------------------ Reporter: howarth@… | Owner: jeremyhu@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: libstdcxx | ------------------------+------------------------ Comment (by jeremyhu@…): Replying to [ticket:38814 howarth@…]:
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.
Within libstdc++, the host's libunwind (from the host's libSystem) is being used: {{{ ~ $ nm -m /opt/local/lib/libstdc++.6.dylib | grep _Unwind_ (undefined) external __Unwind_DeleteException (from libSystem) (undefined) external __Unwind_GetDataRelBase (from libSystem) (undefined) external __Unwind_GetIPInfo (from libSystem) (undefined) external __Unwind_GetLanguageSpecificData (from libSystem) (undefined) external __Unwind_GetRegionStart (from libSystem) (undefined) external __Unwind_GetTextRelBase (from libSystem) (undefined) external __Unwind_RaiseException (from libSystem) (undefined) external __Unwind_Resume (from libSystem) (undefined) external __Unwind_Resume_or_Rethrow (from libSystem) (undefined) external __Unwind_SetGR (from libSystem) (undefined) external __Unwind_SetIP (from libSystem) ... }}} I am not disputing that libstdc++.6.dylib may be using the FSF unwinder in other places, but I have yet to be proven that.
In a perfect world, the static libgcc_eh would be rewritten to use the same code used for the compatibility unwinder in libSystem ... 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.
If your analysis is correct, this will simply fix the issue for libstdc++, but the issue will remain for anything else that is linked using -static- libgcc. Therefore, we should fix the issue with -static-libgcc rather than doing a 1-off fix for libstdc++.
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.
Yes, I agree. We should probably maintain libstdc++.a for each compiler. But let's tackle that separately. This ticket is about getting libstdc++.dylib to be built properly. I would much prefer to see a fix that involves gutting the offending code from libgcc_eh.a that should be resolved to the host, but I don't see any: {{{ $ nm /usr/lib/system/libcompiler_rt.dylib | grep -v ' U ' | awk '{print $3}' | sort -u > /tmp/host_compiler_rt $ nm /usr/lib/system/libunwind.dylib | grep -v ' U ' | awk '{print $3}' | sort -u > /tmp/host_unwind $ cat /tmp/host_compiler_rt /tmp/host_unwind | sort -u > /tmp/host $ nm /opt/local/lib/libstdc++.6.dylib | grep -v ' U ' | awk '{print $3}' | sort -u > /tmp/libstdcxx $ comm -12 /tmp/libstdcxx /tmp/host }}} Since your issue is resolved by changing the linking, I'm waiting for you to tell me what is being resolved incorrectly into libgcc_eh.a which should be resolved into libSystem. --- Furthermore, in another ticket, you said that the issue was about bootstrapping and not multiple unwinders. That seems to make more sense given the evidence here so far. Did you yet try reverting r103047 from #36116? -- Ticket URL: <https://trac.macports.org/ticket/38814#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X