-mmacosx-version-min=10.6 behavior with additional libgcc_s.1.dylib's
-mmacosx-version-min=10.6 behavior with additional libgcc_s.1.dylib's
- Subject: -mmacosx-version-min=10.6 behavior with additional libgcc_s.1.dylib's
- From: Jack Howarth <email@hidden>
- Date: Fri, 4 Feb 2011 07:28:26 -0500
Nick,
Can you please confirm that the following analysis of the limitations
for handling additional physcial copies of libgcc_s.1.dylib by the linker
and dyld under -mmacosx-version-min=10.6 is correct? In FSF gcc 4.5, in
order to access all of the additional symbols added to the FSF libgcc_s.1.dylib
after the symbol set for libgcc_s.10.5.dylib was defined, versioned copies
of libgcc_ext.10.4.dylib and libgcc_ext.10.5.dylib were introduced. These were
stubs to the FSF libgcc_s.1.dylib which only exported those symbols not present
in the matching libgcc_s.10.4.dylib and libgcc_s.10.5.dylib. The linkage order
of -lgcc_s.10.5 -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem was used for
both -mmacosx-version-min=10.5 and -mmacosx-version-min=10.6. This results in
a linkage order (as viewed by 'otool -L') of...
/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)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)
In FSF gcc 4.6, in attempt to remove the /usr/lib/libgcc_s.1.dylib linkage for
-mmacosx-version-min=10.6, this linkage was changed to just..
-lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem
so that 'otool -L' shows...
/sw/lib/gcc4.5/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.1)
However, while testing builds of xplor-nih (which contains shared libs built with -flat_namespace)
using FSF gcc 4.6, I discovered that the exception trackback could become broken and would crash
out in the FSF libgcc_s.1.dylib's unwinder.
Comparing how Apple gcc 4.2.1 and clang produced linkages under -mmacosx-version-min=10.6, I
noticed that both precedes -lgcc with -lSystem. However, for FSF gcc 4.6 under -mmacosx-version-min=10.6,
using just...
-lgcc_ext.10.5 -lSystem -lgcc -no_compact_unwind -lSystem
which retains the linkage order (as seen by 'otool -L') of...
/sw/lib/gcc4.5/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.1)
was insufficient to eliminate these exception traceback failures when using -flat_namespace.
Only the linkage...
-lSystem -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem
which produces the linkage order (as seen by 'otool -L') of...
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.10)
/sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
eliminates the exception traceback failures with -flat_namespace.
It is my belief that it is an incorrect assumption that, under -mmacosx-version-min=10.6, the
stub mechanism alone will prevent the unexported symbols in the /sw/lib/gcc4.6/lib/libgcc_s.1.dylib
from being used by the darwin linker. In other words, for -mmacosx-version-min=10.6, any additional
copies of libgcc_s.1.dylib have to be treated the same as the -lgcc linkage and must be preceded by a
linkage on -lSystem to insure that its symbols are used. The fact that the /usr/lib/libgcc_s.*.dylib
files are all symlinks back to libSystem (which contains magic symbols for those in libgcc_s.10.4.dylib
and libgcc_s.10.5.dylib), makes me suspect that the stub mechanism of limiting the exported symbols
from additional physical copies of libgcc_s.1.dylib is insufficient alone to prevent the unexported
symbols in libgcc_ext.10.5.dylib from being used (hence the traceback into FSF gcc's libgcc_s.1.dylib's
unwinder) for -mmacosx-version-min=10.6.
Can you confirm that this analysis, that either the design of the linker and dylib for
-mmacosx-version-min=10.6 doesn't expect an additional physical linkage on another
libgcc_s.1.dylib before libSystem.dylib or that this is a bug in the handling of stubs in the
case -mmacosx-version-min=10.6, is correct? Thanks in advance for any advice.
Jack
ps I would also note that only the use of "-lSystem -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem"
causes the duplicate symbol for ___divdc3 is gotten from libSystem again and failures in the FSF gcc
gcc.dg/torture/builtin-math-7.c re-exposed (<rdar://problem/7457013> ___divdc3 slightly wrong).
Iain is resisting the proposed change to the linkage order for -mmacosx-version-min=10.6 because the
details of how the magic symbols in libgcc_s.*.dylib operate are undocumented. Any clarifications will
be greatly appreciated.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden