Much for the same reason we need to limit a process to one libstdc++.dylib in 
its address space, we need to ensure that there is only one emutls 
implementation since lookups can cross between implementations (cf: the recent 
thread titled "Problem with gcc4.7 and call_once" on macports-users).  In the 
case of that thread, one emutls implementation was static to libstdc++ and one 
was linked into the main executable via libgcc_s.  The static nature of the 
first emutls is irrelevant, the issue persists if using a different dynamic 
libgcc_s in libstdc++.

This means that we should bundle up a single libgcc_s like we do libstdc++.  
I'm wondering how much more of the gcc runtime libraries we want to do this 
with.  If we were a distro where we could easily build once and master to 
different binary packages, then we could easily break this up into multiple 
packages, but we're not.  I'm trying to decide what goes into "libgcc" and what 
stays provided by the individual compilers.

Please take a look at the attached libgcc.patch which is my proposed solution 
to this problem.  This obsoletes the libstdcxx port for a libgcc port which 
provides:

$ port contents libgcc
Port libgcc contains:
  /opt/local/lib/libgcc/libasan.0.dylib
  /opt/local/lib/libgcc/libatomic.1.dylib
  /opt/local/lib/libgcc/libgcc_s.1.dylib
  /opt/local/lib/libgcc/libgfortran.3.dylib
  /opt/local/lib/libgcc/libgomp.1.dylib
  /opt/local/lib/libgcc/libitm.1.dylib
  /opt/local/lib/libgcc/libobjc-gnu.4.dylib
  /opt/local/lib/libgcc/libquadmath.0.dylib
  /opt/local/lib/libgcc/libssp.0.dylib
  /opt/local/lib/libgcc/libstdc++.6.dylib
  /opt/local/lib/libstdc++.6.dylib

The last entry is a symlink for binary compatibility.

gcc4X ports that would provide these will instead symlink them (just like they 
were libstdc++.6.dylib with the libstdcxx port).

Since the gcj runtimes bump their version with every gcc release, those aren't 
being provided by libgcc.

Additionally, some older gcc versions have binary incompatible libobjc-gnu, so 
I will likely also add a libobjcgnu2 subport to gcc45 to provide 
/opt/local/lib/libgcc/libobjc-gnu.2.dylib and update gcc4[2345] to symlink that 
one.

I'd like to leave this open for testing and discussion for a few days.  Please 
let me know your thoughts and concerns.

Thanks,
Jeremy


Attachment: libgcc.patch
Description: Binary data

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to