[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ML branch: relinking on linux?

From: Michael Matz
Subject: ML branch: relinking on linux?
Date: Tue, 12 Dec 2000 10:21:43 +0100 (MET)


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 convenience lib)
b/  (a shared lib)
c/  (shared, links in "../a/ ../b/")

All are C++ libs.

Note, that is created normally (I mean without a relink_command in
the .la file), but 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
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"

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]