relinking hardcode_into_libs=all linux

[Michael Matz]

Hi,

due to lack of responses I want to reiterate on the subject (I already
asked something in
http://mail.gnu.org/pipermail/libtool/2000-December/004179.html, with only
a response from NetBSD's Nick Hudson).  The problem and basic
circumstances are the same as in that mail (a.la a conv-lib, b.la a shared
lib, c.la also shared linked against a.la and b.la).  Fast install is
enabled.  Only c.la gets a $relink_command.  There are some necessities
for this to happen:

1) $need_relink has to be set by libtool itself.  For reasons unknown to
   me the condition for this seems to be, when one deplib is uninstalled,
   is shared and somehow static libs are not prefered, in shell-speak:
     if test -n "$library_names" &&
        { test "$prefer_static_libs" = no || test -z "$old_library"; } &&
        test "$installed" = no;
   (around line 2044 of ltmain.in)
   Someone want to explain to me, why the above condition is correct?
   Just out of interest.
2) The actual output of the link_command line into the .la file takes
   place simply when $need_relink is set (and $installed=no, which is true
   in one iteration of that loop around line 4325)

Attached are two patches for illustration only.  They are basically the
splitted "hardcode_into_libs=all removal" patch for ltmain.sh (not .in)
but only those hunks which make a difference on linux (were
hardcode_into_libs=yes), i.e. a hunk which transforms "if cond1 ||
hardcode_into_libs=all ;" into "if cond1" I applied anyway, because for
linux the conditions are really equivalent.  The first diff does
everything which the removal of =all does, (where the semantic for linux
changed), except the actual output of the relink_command line, which is
what the second diff does.

This is the behaviour of libtool without both patches (so ltmain.in in
this respect in the state before the removal somewhen last year):
* all shared libs get linked without any -rpath flags.
* the created libs are those which get installed
* executables get linked with -rpath to the final destination dirs, also
  for yet uninstalled libs.
* when the uninstalled exes are run, they get relinked with more -rpath's
  prepended to first find the uninstalled libs.
* This is the behaviour I want.

With the first diff applied:
* shared libs get linked with -rpath set to .libs directories, were the
  uninstalled libs are created (for deplibs). In the example c.la is
  created with an "-rpath /.../b/.libs" (when b.la was placed into
  /.../b/).  I could understand why that binary would not be installed,
  because of the wrong rpath's.  But see below for the exes.
* shared libs are not relinked at install time (because of the missing
  second patch only), instead are installed with the "wrong" rpath.
* exes are linked with -rpath's set to the install locations of libs (even
  for uninstalled ones).  When run they are relinked to also have -rpath's
  to the uninstalled locations.  The -rpath in the exe seems to override
  any rpath in the libs, so if the libs and the exe are installed, that
  installed exe takes the right libraries (the installed ones), although
  the libs have wrong -rpath's (that's why I ""'ed wrong above).
* This is behaviour I could live withm, as nothing get's relinked at
  install time.

With finally the second diff applied, making ltmain.sh the same as
CVS-MLB-current:
* shared libs are created like above (-rpath to .libs")
* those libs which depend on uninstalled libs get relinked at install
  time, with -rpath's only to install locations
* exes are created like above
* This behaviour is unacceptable (as a comment in ltconfig says, to which
  I aggree)

So, what is the solution for linux (or genarally)?
Don't define hardcode_into_libs=yes? (which is the reason for that
definition? to make modules work?)
The restore of the old behaviour but some tweaks to address Nick's
concerns with NetBSD which originally resulted in the removal?

So far this topic.

The following is not my main concern for this mail, but I wanted to ask
anyway, because more information would likely have avoided this mail
alltogether:

Does anybody remember and can list for me the exact relationships between
the relevant shell variables and behaviour in libtool?  What different
platforms exist behaviourwise (restrictions)?  How does this behaviour map
to the multiple variables?  When should some vars be set to which value
(are the current settings correct and needed for their platforms)?
What should be the behaviour of libtool when those vars are set to those
values?  Does that behaviour match the above restrictions for a platform?

I realize, some of the questions are "answered" in comments.  E.g. the
variables are commented, so it often is clear when a variable should be
set, if a platform has a special behaviour.  The problem is, that those
comments often describe the same thing, as the var name itself already
does.  What really is missing are comments about why libtool takes certain
paths, when vars are set to certain values, i.e. comments about the
desired effect the vars should have on the compile/link commands, and more
comments in libtool connecting this desire for effect with actual
decisions in ltmain itself.  I can guess, over time contributors forgot
why libtool did something in the way it did it, resulting in bugs.


Ciao,
Michael.

ltmain.sh.diff5
Description: Text document

ltmain.sh.diff6
Description: Text document