* Ralf Wildenhues wrote on Wed, Nov 30, 2005 at 11:07:47PM CET:
>
> Hmm. Sounds like quite a bit of work. And pretty dangerous, too. We'd
> need lots of good tests. One thing to always keep in mind (for upstream
> GNU Libtool) is that this change of operation must not change anything
> on other systems.
Just to give an idea about what good test coverage would be:
Let P be a program, arrows indicate direct linkage.
Make dead sure we find and use the correct (un)installed libraries, for
both the uninstalled and the installed program:
- P --> libA or P --> libA --> libB or P --> libA --> libB
`-> libB
- both uninstalled,
A un-, B installed,
both installed
- A and B (to-be-)installed in same libdir, or different one
- A and B (to-be-)installed in a default-searched dir
(for either the link editor or the runtime linker)
- there exist previously installed versions of one or
both of the libraries
- either link-time or runtime incompatible
- in either the same libdir as the new ones will be,
or other ones which are involved, or the default-
searched dirs (for either the link editor or the
runtime linker)
[ I have no idea how to put the latter in a testsuite run by non-root ]
- maybe combine with (low-priority):
-static, -all-static, or configured --disable-static.
If all these combinations work out fine, then there is still a whole
class of issues yet to be solved: dlopening with library dependencies.
So, now let dotted arrows indicate lt_dlopen()ed modules, M a module,
D another library (libC is on some systems the C++ standard library).
Something like this set of combination, or a bit less:
- P ..> M
P --> libA ..> M
P ..> M --> libB --> libD
`-> libB
P ..> M --> libB --> libD
`-> libB
`-> libD
P --> libA ..> M --> libB -> libD
P --> libA ..> M --> libB
`-> libB
P --> libA ..> M --> libB -> libD
`-> libD
P --> libA ..> M --> libB -> libD
`-> libB
`-> libD
P --> libA ..> M --> libB
`-> libB
P --> libA ..> M --> libB
`-> libB `-> libB
P --> libA ..> M --> libB -> libD
`-> libB
P --> libA ..> M --> libB -> libD
`-> libB
`-> libD
P --> libA ..> M --> libB -> libD
`-> libB `-> libB
`-> libD
- repeat above list of combinations, expanded by M and libD, but do not
try *all* possibilites (around 200M if I'm not mistaken) -- rather
find a good representative subset (maybe a couple hundred).
- It may even be useful to consider the case where installed modules
depend on uninstalled libraries. I don't think this is particularly
elegant, and it's clearly not portable, but disallowing this is likely
to hurt some of the more elaborate packaging schemes (say, browser
with lots of third-party plugins); rather, the lower-level libs (in
this case libB) should be packaged separately from P and libA, so that
M may be built before them but after libB.
- I'm not certain we also need to take into account modules loading
other modules, or multiple modules depending on different lower-level
libraries.
- DESTDIR installs or cross-compilation have not been taken into account
*just* yet.
One reason I'm writing this is that it may be useful to have this set of
tests not only in the "link_all_deplibs=no Debian libtool", but also in
upstream GNU Libtool. I also think that an eventual merge upstream will
be much easier, say, if the link_all_deplibs choice were not one done at
configure time based on $host only, but maybe based on a configuration
switch, or even a "libtool --mode=link" time switch (or an environment
variable containing that switch). The best choice here is not yet clear
to me, as issues like #297726 and #291641 should be fully understood and
fixed first.
This would likely require Debian to change their build machinery a bit,
but I think it has ways to centralize this in a single or few places
(and I think it can be done in a way that it won't need a "flag day").
Anybody with too much time on their hands is cordially invited to write
tests for this, preferably for CVS HEAD with help of the Autotest test
suite (stresstest.at is a good example of how to tackle this).
(I may be abusing the Debian BTS as a TODO list; sorry about that.)
Cheers, and thank you for reading this far,
Ralf
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
