Re: Shared library annoyance with gcc-3_0-branch

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Brad" == Brad Lucier <lucier@math.purdue.edu> writes:

    Brad> I don't want all the libraries I use linked statically.  I
    Brad> just want the library that I never had to think about
    Brad> before, and indeed, never noticed before, linked in
    Brad> automatically (whether statically or not).

Then you should indeed build --enable-static.  If you had used any
language other than C, and used --enable-shared, you would already
have had this problem.  For example, with C++ shared libraries, you
would have had this problem.  With Java shared libraries, you would
have had this problem.

    Brad> My pain also comes from keeping three production versions of
    Brad> gcc on my alpha box for various purposes and two test
    Brad> versions.  In the future, if this need for multiple versions
    Brad> of gcc for various reasons continues, I don't see how I will
    Brad> be able to set LD_LIBRARY_PATH once and be done with it.

You can use -rpath if you want.  Or you can build --enable-static.  Or
you can use -static-libgcc.  Or you can use -static.

I think it should be the case that in the default configuration the
compiler produces code that works correctly.  Without a shared libgcc,
and without linking shared libraries with the shared libgcc, that
doesn't happen.

I understand that you're running into a nuisance.  In the medium to
long term, I don't think the typical user will have multiple GCCs
lying around (everyone will now tell me that they do, but remember
that you're reading this list, so you're not a typical user...).  On
GNU/Linux systems, that one GCC will be in /usr, and everything will
just work.  Or libgcc will be in libc, and things will just work.  On
other systems, you'll have to set LD_LIBRARY_PATH -- but you would
have had to anyhow for C++ or Java applications.

I really don't think we're going to make a lot of progress in this
debate.  The arguments are clear and valid on both sides.  Clearly,
some people value the costs and benefits differently.  There's nothing
we can do about that.

The good thing is that there are options to disable the behavior you
don't like.  So, all we're arguing about is the default behavior.  I
think we're just going to have to agree to disagree -- both sides
can't win.

Sorry,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com