RFC: libgcc port

[Jeremy Huddleston Sequoia]

For anyone interested in testing these changes, here'a an updated patch that addresses some issues I noticed in testing, including some fixes for +universal.

Thanks,
Jeremy


-------------- next part --------------
A non-text attachment was scrubbed...
Name: libgcc.patch
Type: application/octet-stream
Size: 42547 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130811/2f651d80/attachment-0001.obj>
-------------- next part --------------

On Aug 11, 2013, at 9:54, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote:

> 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
> 
> 
> <libgcc.patch>_______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20130811/2f651d80/attachment-0001.p7s>