site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Mutt/1.5.18 (2008-05-17) 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. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com