[Top][All Lists]

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

Re: finish mode needed for plugins?

From: Stefan Kost
Subject: Re: finish mode needed for plugins?
Date: Mon, 27 Oct 2008 23:01:33 +0200
User-agent: Thunderbird (X11/20080922)


Ralf Wildenhues schrieb:
> * 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

that would work. good idea.

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

I think you lost me a bit on the DESTDIR proposal. About "DESTDIR" you mean the
variable beeing empty or the directory beeing empty? I guess its the var. This
would still only help if we install multiple files in one go.

I see two ways:

1) The project requests libtool to not run finish_cmds. Not so nice as this
might break on some platform. Atleast the project would need to be able to run
libtool --mode=finish manualy then.

2) When configuring libtool for a certain platform, it could disable finish
commands for modules for platforms where its known to be safe. There could be a
configure option to --finish-cmds-for-modules={on|off|auto}, so that an admin
could turn it always on if its needed.

> Cheers,
> Ralf

thanks for doing the patch proposal.


reply via email to

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