http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.02.02 09:12:46
     Ever Confirmed|0                           |1

--- Comment #32 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-02 09:12:46 
UTC ---
(In reply to comment #31)
> I can confirm that adding -flat_namespace to the linkage of xplor using stock
> gcc trunk is insufficient to eliminate the crashes in the FSF libgcc unwinder.

comment #30 and comment #31 are as one would expect.

adding -flat_namespace pushes the responsibility onto the build to ensure that
the libs are presented in the correct order for the design (when symbols appear
in more than one lib).  That includes libs provided by GCC - although (maybe)
the User should not have to think about that.  It also includes placement of
the libs in search paths at load/execute time (outside of our control).

One way of controlling the [link time] order (with the #24 patch in place) is
to add -flat_namespace to the exe too.   Equally, one could ensure that the
build references /usr/lib/libgcc_s.10.5.dylib or libSystem before
/my/install/path/libgcc_s.1.dylib.

Ultimately, the 'fix' to this is to ensure that the lib we install to provide
the extensions does not export the other symbols (then we won't care about of
the order of libs or DYLD_LIBRARY_PATHs).  However, this is not something for
stage 4,  and I expect that there will be test-suite fall-out when we implement
it.

So.... either

1/revert 163267 as proposed, 
Are we sure that it has no effect on any other (esp. Java) test-cases? 

2/ Patch @ comment #24 is a work-around that only changes the order for flat
namespace.

If we do #2, then we should add Zforce_flat_namespace as Jack pointed out in
comment #27 like so:

%{Zflat_namespace|Zforce_flat_namespace: 

3/ %L %G %L 
If (1) doesn't work then neither will this.

So - the permutations need reg-strapping (on Darwin 10 at least) - I'll do a
sanity check on Darwin 9 - although it should be unaffected.

Reply via email to