Re: libtool doesn't hardcode libg2c when linking with g77

[John David Anglin]

> If we hardcode the path, the resulting programs would insist
> that the compiler be installed in the same place on any

This is correct if the hardcoding uses the "../../../" scheme used by
GCC 3.X to allow users to move a compiler installation using symlinks.
However, the scheme causes problems under HP-UX with the SOM linker.
It hardcodes shared libraries and there is no way to override this
behavior.  Thus, it is not possible to delete the GCC installation
or move it, unless every app compiled with GCC is deleted or moves
in tandem (yuck).  Because of this undesirable behavior, I am
considering reverting to the 2.95 behavior which didn't use the
"../../../" scheme.  As a result, users will not be able to move
a GCC installation using the SOM linker after it is installed from
its configured location.  However, it removes the dependence of
binaries on the GCC installation directories.  This is clearly
unacceptable for binaries that are to be distributed.  If a user
wants to move GCC, it is probably better to just rebuild it for
the new location.

Things are different for ELF-64 ABI.  There, the linker does not
hardcode by default.  If you want to hardcode, it is via an
embedded path.  Again, I don't much like the idea of hardcoding
with the "../../../" scheme as it introduces a dependence on the
GCC installation.  Possibly, it would be possible to hardcode
with and without dots.  In a "normal" link, LD_LIBRARY_PATH
(and SHLIB_PATH) are enabled and searched before the embedded
path.  Thus, it is still possible to override the embedded
path.

When gcc 3 was released, it became difficult to install it 
in the same location as used for other packages because of
various bits of antisocial behavior.  I have just fixed GCC's
include search behavior to allow packages to be installed
at the same prefix as GCC without causing configuration
difficulties.

> user's machine.  It would not be possible to swap out a
> different version of the library either.  The short answer

I don't believe that that hardcoding significantly affects
the difficulty in switching compatible library versions.  This
is tricky at best.  Under HP-UX, a shared library can't be removed
if any running binary is using it.  It can be moved, but then
other binaries which use it won't work.  Obviously, using
LD_LIBRARY_PATH to switch to a temporary version is one way
to work around this problem.  The other is to have a set of
statically linked tools handy.

> is that if you need to change $LIBATH/$SHLIB_PATH/$LD_LIBRARY_PATH/%PATH%
> (or whatever) then you should, hardcoding the path will cause other

I'm not a huge fan of this approach as multiple ABIs, multiple GCC
installations may cause one to constantly have to redefine the environment
value.  In most cases, I'd rather have the binary find the library it
was "linked" with.  As far as I am aware, there is no other way to
change the search paths of the HP-UX dynamic loaders.

> problems.
> (IMHO)

If hardcoding is such a problem, why does libtool do it?  As I have said,
I'm not totally sure libtool should hardcode GCC libraries but it does
hardcode other libraries into binaries and shared libraries.  As I see
it, the advantage is things just work without having to set an environment
variable.  The disadvantage is that you may have to rebuild binaries
and libraries if you want to move them.

Dave
-- 
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)