[MacPorts] #36093: libstdcxx can't resolve ___emutls_get_address

[MacPorts]

#36093: libstdcxx can't resolve ___emutls_get_address
--------------------------------+------------------------
  Reporter:  angelo.graziosi@…  |      Owner:  jeremyhu@…
      Type:  defect             |     Status:  closed
  Priority:  High               |  Milestone:
 Component:  ports              |    Version:  2.1.2
Resolution:  fixed              |   Keywords:
      Port:  libstdcxx          |
--------------------------------+------------------------

Comment (by howarth@…):

 Please make sure you don't degrade the FSF gcc testsuite results by
 disabling libgcc_ext if you do so. In particular one reason for[[BR]]
 using FSF gcc would be to utilize libgomp (whose functionality isn't
 available in clang yet). [[BR]]
 Also, per your comments in...[[BR]]
 [[BR]]
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54806#c8 [[BR]]
 [[BR]]
 and the fact you are using binary distributions, how will you handle the
 following situation?[[BR]]
 1) The user installs a MacPorts package prebuilt against gcc48[[BR]]
 2) The user also has gcc47 installed.[[BR]]
 [[BR]]
 What prevents the binaries built against the libstdc++ from gcc48 from
 running against the libstdc++ from gcc47.[[BR]]
 In attempting to collapse the number of libstdc++'s installed to a single
 one, how do you insure that new features added[[BR]]
 in c++ for a newer FSF gcc release are properly supported in the libstdc++
 used? If you are using a single libstdc++, will[[BR]]
 it always be generated from the newest gcc4x package in MacPorts? If so,
 will it really be compatible when used with[[BR]]
 c++ code generated from the older FSF gcc4x packages? This seems like an
 awful lot of assumptions on backward compatibilty[[BR]]
 would have to be made.

-- 
Ticket URL: <https://trac.macports.org/ticket/36093#comment:31>
MacPorts <http://www.macports.org/>
Ports system for Mac OS