[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 jeremyhu@…):

 Replying to [comment:31 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]]

 Jack, I've already told you that we haven't disabled libgcc_ext.  Also, if
 we do, we will of course test beforehand.


 > 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]]

 If the user installs a Macports package built against gcc48, then they
 need to have libstdcxx-devel installed, and that will be handled by the
 dependency tree.  The package will have a depends_lib on gcc48 which has a
 depends_lib on libstdcxx-devel.  I don't see the problem.


 > What prevents the binaries built against the libstdc++ from gcc48 from
 running against the libstdc++ from gcc47.[[BR]]

 The fact that they can't both be installed at the same time.  If they have
 gcc48 on their system, they can't have gcc47's libstdc++ because gcc48
 depends on libstdcxx-devel whereas gcc47 can use libstdcxx or libstdcxx-
 devel

 > 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?

 Yes.  Look at the Portfiles.  It is always generated from the newest gcc4x
 packages.

 > If so, will it really be compatible when used with[[BR]]
 > c++ code generated from the older FSF gcc4x packages?

 It's supposed to be.

 > This seems like an awful lot of assumptions on backward
 compatibilty[[BR]]
 > would have to be made.

 Yes, we make such assumptions across all our packages.  We don't expect
 that upstream will break backwards compatibility, and if they do, we
 expect that they will do it in a logical manner.

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