Re: ML branch: relinking on linux?

[Nick Hudson]

Michael Matz wrote:
> 
> Hi,
> 
> I currently don't have time to really look into it, so the description of
> the current behaviour of libtool might seem a little wishy-washy, but I
> mention it anyway, in case anybody knows right away what caused this:
> 
> Basically libtool is relinking when installing, even on linux. Situation
> in question is something like:
> 
> a/a.la  (a convenience lib)
> b/b.la  (a shared lib)
> c/c.la  (shared, links in "../a/a.la ../b/b.la")
> 
> All are C++ libs.

I'm having some problems with MLB libtool and KDE2 as well.

> Note, that b.la is created normally (I mean without a relink_command in
> the .la file), but c.la has a relink command. It had that never before I
> updated our libtool to HEAD. The former was from 1. August. I believe it
> has to do with the change in "hardcode_into_libs=all" behaviour, but
> haven't time right now to really investigate.

The change you mention (1.232->1.233 on head or 1.200.2.34->1.200.2.35
on MLB) was introduced after I was having trouble with NetBSD. NetBSD
has the following set (for ELF)

        hardcode_into_libs=yes
        shlibpath_overrides_runpath=yes

        hardcode_direct=no
        hardcode_minus_L=no
        hardcode_shlibpath_var=unsupported

libtool doesn't seem to think that such a platform can do ILD without
relinking because of hardcode_into_libs=yes. I never really understood
why this is the case.

I've just done some testing to confirm what I thought - that this
shouldn't (necessarily) be the case. Here's how I think it could work...

All libraries are linked with the right options to hardcode the INSTALL
directories. For operations that need the uninstalled libraries then
LD_LIBRARY_PATH (or whatever shlibpath_var is) can be used to override
the install directories.

> ...I only know, that
> $need_relink (which is configured to "no") is set to "yes" by:
> 
> (around line #1924 ltmain.sh)
> if test -n "$library_names" &&
>    { test "$prefer_static_libs" = no || test -z "$old_library"; }; then
>      if test "$installed" = no; then
>         uninst_deplibs="$uninst_deplibs $lib"
>         need_relink=yes
>      fi
>    ...

I'd agree that this isn't the problem...

> But as far as I can see _that_ sequence hasn't changed since august. Only
> in the creation of the .la files (around line #4037) the output of
> "relink_command=..." was guarded by a "if test $hardcode_into_libs = all".

and that this is...


> What should be done, or was this intentional? The ChangeLog seem to
> indicate some confusion regarding hardcode_into_libs.

I think the orginal code was on the right track, but just missed
something for NetBSD case...

Nick
-- 
aka address@hidden, address@hidden