[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 2.0.0.17 (X11/20080922) |
hi,
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.
Stefan
- Re: finish mode needed for plugins?, (continued)
- Re: finish mode needed for plugins?, Bob Friesenhahn, 2008/10/22
- Re: finish mode needed for plugins?, Stefan Kost, 2008/10/22
- Re: finish mode needed for plugins?, Bob Friesenhahn, 2008/10/22
- Re: finish mode needed for plugins?, Stefan Kost, 2008/10/23
- Re: finish mode needed for plugins?, Bob Friesenhahn, 2008/10/23
- Re: finish mode needed for plugins?, Ralf Wildenhues, 2008/10/23
- Re: finish mode needed for plugins?, Stefan Kost, 2008/10/24
- Re: finish mode needed for plugins?, Bob Friesenhahn, 2008/10/24
- Re: finish mode needed for plugins?, Stefan Kost, 2008/10/25
- Re: finish mode needed for plugins?, Ralf Wildenhues, 2008/10/26
- Re: finish mode needed for plugins?,
Stefan Kost <=
- Re: finish mode needed for plugins?, Ralf Wildenhues, 2008/10/27
- Re: finish mode needed for plugins?, Stefan Kost, 2008/10/27