Re: Please review 3.4 patches

["H. J. Lu" <hjl at lucon dot org>]

On Tue, Nov 02, 2004 at 08:47:36AM +0100, Jakub Jelinek wrote:
> On Mon, Nov 01, 2004 at 10:01:47PM -0800, Mark Mitchell wrote:
> > >http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00795.html
> > 
> > This last one, at least, is clearly wrong.
> > 
> > You're now defaulting to --enable-shared, even on systems that may not 
> > support shared libraries at all.
> > 
> > What's wrong with Joe's suggested solution: set LD_LIBRARY_PATH when 
> > running programs from the stage1/ or stage2/ directories?
> > 
> > Also, do we have a list of the patches that went in post GCC 3.4.2 that 
> > are causing problems?  I want to know what we will have to take out if 
> > we have to take things out.
> 
> I think the libunwind patch is the most problematic one and should not made
> it into the stable branch, just HEAD (and even there I don't like it very
> much).
> It e.g. forces using davidm's libunwind always, as GCC built libunwind.so.7
> can't reasonably coexist with davidm's libunwind.so.7 (which some programs
> like gdb want to use) and adds one extra shared library to all programs that

The whole idea is all implementations of libunwind.so.7 should be
compatible with each other. Users shouldn't be able to tell the
difference. Otherwise, we failed to achieve our goal. Does David
know this problem?

> need EH (the whole C++ world, plus C using cancellation).

That is what the ia64 unwind ABI calls for. If an ia64 program needs
unwind, it should be linked against libunwind.so.7.

> I think better alternative would be to link in only libgcc_s.so.0
> when configured without system unwind and when configured with system
> libunwind, have wrappers exported from libgcc_s.so.0 that would immediately
> jump to the libunwind.so functions.  That way binary compatibility between
> --without-system-libunwind and --with-system-libunwind GCC would be ensured
> as well.

I don't think we have a binary compatibility here. The problem is

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

which also affects libgcc_s.so.


H.J.