[MacPorts] #38814: libstdcxx subport's linkage on libgcc_eh.a incorrectly causes the usage of two different unwinders

[MacPorts]

#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