This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [patch] releases.html


On Tue, Feb 13, 2001 at 02:13:00AM -0500, Daniel Berlin wrote:
> 
> Is there any disagreement that about the only thing we could do to
> make the current Makefile based stuff worse, would be to add libtool? 

I bet you I could make the Makefile worse without coming anywhere near
libtool.

My attitude on target shared libraries is that if we can't make -fPIC
at compile time and -shared -soname <whatever> at link time do the
right thing, then we don't support shared libraries on that target.
(That should include the libraries that are built with libtool now,
btw.)

Host shared libraries are not significantly harder.  In a native
bootstrap, we can just not generate any until phase 2, then insist on
-shared again.  In a build != host situation, we insist on gcc for the
build compiler, with a functional -shared.

Then there's the issue of rpaths.  This gets hairy.

(1) for hypothetical host shared libraries linked into cc1 etc., have
    the driver set LD_LIBRARY_PATH.  [Is there any target where
    LD_LIBRARY_PATH isn't the way to get the dynamic linker to search
    somewhere exotic?]  This preserves location independence.

(2) for target libraries, have collect2 set -rpath in the linker if
    and only if the library in question is not on the target's
    "standard" search path.  (/usr/lib:/lib on most Unixes).

Should we need dynamic _loading_ functionality, we can stick some
wrapper routines in libiberty.

---

And if someone wants to make the Makefiles *better*, well, there's a
nice long list of suggestions over at gcc.gnu.org/projects/beginner.html.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]