Re: finish mode needed for plugins?

[Ralf Wildenhues]

* Stefan Kost wrote on Fri, Oct 24, 2008 at 09:02:45AM CEST:
> Ralf Wildenhues schrieb:
> > Two data points: First, I think one plain reason for running finish_cmds
> > may be simply that some people misuse modules also as libraries to link
> > against.
> >
> Thats true. I am actually link against uninstalled modules for unit-test and
> documentation purpose. But then, no finish_cmd has been run yet anyway.

But libtool takes explicit measures to allow you to link against
uninstalled libraries, so that doesn't count as comparison.

> Personaly I think that if that use case would break, its what those
> applications deserve :)

Well yes, I agree.  But that doesn't mean I want to push that burden to
application users, who then have to suffer from application developers'
wrong-doings.

> > Second, the next Automake release will install several files at once;
> > AFAICS that means ldconfig will also be run a lot less often then, and
> > while not solving this issue, likely making it far less problematic in
> > practice, no?
> That is good news indeed. Unfortunately that will probably only hold for
> multiple modules that come from one directory. I am working in the gstreamer
> project - we have several hundreds on modules and each has a single build 
> directory.

And each of them has a separate Makefile.am, as opposed to: just a
fragment included by another Makefile.am, doing something like
   pkglib_LTLIBRARIES += module42.la

?  I'm not saying you have to sacrifice a clean build tree, but
nonrecursive has some optimization possibilities that recursive
builds just do not allow.  But let's not go into detail here, my
interest in this topic is the main item of the discussion.


It seems there are several possibilities for moving forward:

0) do nothing,

1) drop finish_cmds for modules, hope to avoid widespread breakage.

2) add an option '--no-finish' to 'libtool --mode=install' to avoid
finish_cmds.  This could be useful not only for modules, but libraries
as well.  You could enable it in all but the last directory in which
you install modules, for example (iff there is a fixed such last one),
or manually add an install-exec-hook someplace run late, that does
  libtool --mode=finish $(pkglibdir)...

iff DESTDIR is empty (and only in that case!).  Hmm, maybe we should
even transport DESTDIR to such a finish command, to allow libtool to
output the warning for users.

This change would have the added advantage that automake could, in its
install rule, use -no-finish for all invocations but the last one within
a single installation rule (this bit is only relevant if there is a
directory with very many libraries/modules to install into the same
directory.)

I see two potential use cases that could regress:

* installing liba and libb, libb depends upon liba, and is relinked at
  install time.  Can it be possible that the relink process would need
  the finish commands to have been executed beforehand?  I think not,
  for two reasons: the relink takes explicit steps to add a -L argument
  with the relinked path of liba.  Second, finish commands were never
  done between libs in
    libtool --mode=install install liba.la libb.la $libdir

  Similar for programs relinked upon installation, after the libs but
  before the finish command.  I think in the context of relink mode,
  finish_cmds is relevant only for the runtime linker, not for the link
  editor.

* Utilities needed *during* installation could break.  This is a rather
  special scenario, so far theoretical (but libintl is an obvious likely
  candidate).  If we install libfoo, and one of the programs used during
  installation/relinking of further libraries or programs needs libfoo,
  then not having finished libfoo could break that execution.

I will reply on libtool-patches with a proposed patch, after trying to
find out whether the second scenario is a realistic one or not.
Possibly, it could be worked around by setting LD_LIBRARY_PATH (or its
equivalent) inside the libtool script.

3) I have not thought about further possibilities yet.

Cheers,
Ralf