ML branch: relinking on linux?

[Michael Matz]

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.

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. 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  
   ...

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".
What should be done, or was this intentional? The ChangeLog seem to
indicate some confusion regarding hardcode_into_libs.

I also noticed, that, when creating c.la, the reference to ../a/.libs/a.a
is doubled, one time between the usual --{no}-whole-archive flags, and one
time in the normal deplibs-list.

Ideas?


Ciao,
Michael.