On Thu, 2003-03-13 at 14:52, Josselin Mouette wrote:
> Le jeu 13/03/2003 à 11:38, Scott James Remnant a écrit :
> > If you do, I'll happily patch Debian's package and campaign for the
> > patch upstream.
>
> Go for it, it looks very good.
>
You missed the first bit, lit. doing all that testing first.
> > Look, no dep trawling...
>
> > virus lttest% objdump -p .libs/test | grep NEEDED
> > NEEDED libb.so.0
> > NEEDED libc.so.6
>
> Is it possible to get your patched version of libtool ? Also, are there
> some hacks to achieve that with current libtool ?
>
Of course you may have the patch, especially if you plan to find out
whether this does the right thing or not.
The patch does the following:
1) If the OS is Linux then set link_all_deplibs to "no" rather than
"unknown". Nothing else sets this to "no", so it should only
change Linux behaviour.
2) Don't set dependency_libs if link_all_deplibs is "no". This means
that the dependency_libs line in the .la file will be empty, because
the linker can handle it. It *ALSO* means that the dependency_libs
line from .la files will not be considered when linking (ie you don't
need to recompile everything on your system).
I'm almost positive this will break things, so be very very careful.
Don't just apply this because you like the idea, if you're going to use
this patch *ASSUME* your software will be broken, and test very very
hard accordingly.
How to apply... libtoolize && aclocal && autoconf your software, then
apply the two patches below. The first patches "ltmain.sh" which should
be the same as the file I based the patch on (1.4.3-7). The second
patches "aclocal.m4" (specifically the bits that would have come from
libtool.m4). I deliberately changed one that's probably closest to most
people's (automake & libtool), but you'll probably find that your patch
is offset by a few lines.
Also please note, DO NOT remove the comments... Most people file bugs
with packages using an included libtool against the Debian libtool
package itself, so I need to be able to quickly see whether it's a
patched libtool or not.
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
--- ltmain.sh.orig 2003-03-14 12:51:23.000000000 +0000
+++ ltmain.sh 2003-03-14 14:09:04.000000000 +0000
@@ -2086,7 +2086,16 @@
done
fi
if test $pass != dlopen; then
- test $pass != scan && dependency_libs="$newdependency_libs"
+ # If link_all_deplibs=no then we don't need to link or remember
+ # dependency libraries.
+ # -- Scott James Remnant <keybuk@debian.org>
+ if test $link_all_deplibs != no; then
+ test $pass != scan && dependency_libs="$newdependency_libs"
+ else
+ dependency_libs=
+ fi
+ # keybuk@debian/deplibs -- DO NOT REMOVE THIS COMMENT
+
if test $pass != conv; then
# Make sure lib_search_path contains only unique directories.
lib_search_path=
---->8-------->8-------->8-------->8-------->8-------->8-------->8----
----8<--------8<--------8<--------8<--------8<--------8<--------8<----
--- /home/scott/co/librsssoup/aclocal.m4 2003-03-14 14:20:06.000000000 +0000
+++ ./aclocal.m4 2003-03-14 13:39:30.000000000 +0000
@@ -3000,6 +3000,12 @@
# before this can be enabled.
hardcode_into_libs=yes
+ # Linux's dynamic linker can theoretically do recursive link loading
+ # so don't link in dependency libraries.
+ # -- Scott James Remnant <keybuk@debian.org>
+ link_all_deplibs=no
+ # keybuk@debian/deplibs -- DO NOT REMOVE THIS COMMENT
+
# We used to test for /lib/ld.so.1 and disable shared libraries on
# powerpc, because MkLinux only supported shared libraries with the
# GNU dynamic linker. Since this was broken with cross compilers,
---->8-------->8-------->8-------->8-------->8-------->8-------->8----
Enjoy,
Scott
(who strongly suspects this patch could be considered a Weapon Of Mass
Destruction).
--
Scott James Remnant Have you ever, ever felt like this? Had strange
http://netsplit.com/ things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part