[Top][All Lists]

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

Re: ML branch: relinking on linux?

From: Nick Hudson
Subject: Re: ML branch: relinking on linux?
Date: Tue, 12 Dec 2000 20:56:49 +0000

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

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

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

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



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

aka address@hidden, address@hidden

reply via email to

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