This is the mail archive of the
mailing list for the GCC project.
Re: [patch] releases.html
On Tue, Feb 13, 2001 at 06:38:29AM -0200, Alexandre Oliva wrote:
> On Feb 13, 2001, "Zack Weinberg" <email@example.com> wrote:
> > [Is there any target where LD_LIBRARY_PATH isn't the way to get the
> > dynamic linker to search somewhere exotic?]
> Sure. SHLIB_PATH on HP-UX, LIBRARY_PATH on AIX,
> LD_LIBRARY(N32|64)_PATH on IRIX, PATH on MS-Windows.
Okay, so we have to know that. Mostly a problem for dejagnu in the
present system; may become a problem for gcc.c later.
> Besides, you have to make sure the executables created in the build
> tree use libraries from the build tree, and those that you install
> look for libraries where they're installed. In particular, you don't
> want executables in the build tree to use previously-installed
> libraries nor the installed ones to search the build tree. And, on
> most OSs, setting LD_LIBRARY_PATH or equivalent is not enough to
> ensure you get the right libraries.
I'm not sure it can be got completely right in the general case; you
would want to specify an explicit list of which libraries you expected
to be found where (so that libc was found in /lib, but not
libstdc++...) As long as you avoid -rpath, it seems to me that
setting LD_LIBRARY_PATH does enough of what we want. And avoiding
-rpath is a good idea in general.
> It's not that simple to do it right. Libtool already takes care of
> all these details. It would be a pity to duplicate this work.
I would argue that if we can do it with substantially less complexity
and fragility than libtool, then duplicating the effort is worth it.
And I would argue that we can. Existence proof: perl5 does not use
libtool, yet manages to generate and use shared libraries _and_
dynamically loaded modules in the course of its build. Without
insisting on any particular compiler. I have trouble imagining that
its build system can be _worse_ than libtool.