This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Avoid -lm and -lpthread in libjava on darwin
Ralf,
In case my previous response was unclear, the normal linkage of...
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0)
/sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
reflects the linkage of the versioned libgcc_s.10.[4,5] (which provides all of the symbols
listed in darwin-libgcc.10.[4,5].ver) followed by the linkage of /sw/lib/gcc4.6/lib/libgcc_s.1.dylib
(which provides all of the additional symbols not provided by darwin-libgcc.10.[4,5].ver) followed
by /usr/lib/libSystem.B.dylib. The uncertainty arises when symlinks to libSystem.dylib like
libdl.dylib, etc are linked in as well. This causes the linkage to become...
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0)
/sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
with libSystem pushed forward in the linkage. Since libSystem may contain additional symbols
also provided by /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (like ___divdc3 which were added after
Apple stopped doing new libgcc_s.10.x versions), one can end up with Apple's code or
FSF gcc's code depending on whether -ldl, -lm or -lpthread was passed. The remove-outfile
patch prevents this from happening and creates a certainty as to which code will be used
with FSF gcc.
Jack