http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-01 16:32:13 UTC --- (In reply to comment #19) > (In reply to comment #16) > > (In reply to comment #15) > > > > > > > Perhaps r163267 is fragile to certain combination of linker flags (like > > > -flat_namespace)? > > > > "fragile" LOL... > > > > Considering that Apple has always recommended the use of that flag for porting > unix software... > > http://developer.apple.com/library/mac/#documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html%23//apple_ref/doc/uid/TP40002850-TPXREF101 > > (see the section on Understanding Two-Level Namespaces), it really is not a > very funny bug. I don't consider any bug funny ; however instructing the linker to ignore two-level-namespace is not a 'fragility' on the part of the compiler or its specs. The fault may be considered to be (a) in relying on the two-level-namespace in our extension design if there is a requirement for flat-namespace at the same time as the extensions. [FWIW: originally I posted a patch for a separate lib, which was felt by reviewers to be inefficient, hence the use of the stubs and two-levels.] (b) the build process for the application uses -flat_namespace but is not sufficiently explicit about library paths and library ordering. [using flat namespace requires that you make sure that the libs appear in the order you want them]. --- note, despite the document comments: the use of two level namespace is the Apple default. the Apple tools use the same library ordering that trunk does. In the short-term, we can either revert the patch or apply the alternative [any preference Mike?] which will force the library ordering (after we spent all that effort to ensure that libSystem was _not_ linked first by filtering out -lm etc.) In the longer term, if this really is the 'norm' we will have to re-do the libgcc_ext to be a non-stub library.
