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
libgcc.patch
Description: Binary data
On Aug 11, 2013, at 9:54, Jeremy Huddleston Sequoia <[email protected]> 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 > [email protected] > https://lists.macosforge.org/mailman/listinfo/macports-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
