Hi Kurt, * Kurt Roeckx wrote on Mon, Dec 05, 2005 at 12:52:55AM CET: > > As some of you might know, Debian has a patch to reduce the > number of libraries that libtool will link too.
Yes. And it's a support nightmare, not only for Debian Libtool, but for us as well, because people do not recognize it's the Debian changes that break their builds. When I have time, I'd like to fix your current issues with it, namely cross-compilation[1], and wrong-libs-for-uninstalled-programs[2]. And also, I very very much would like to change the way this is enabled, in order to both - make this usable for non-Debianers - not unconditionally turn this on for unsuspecting Debian users I've laid out more detailed ideas in [3]. It would be very helpful if the Debian community could agree to some solution -- maybe something like: your build infrastructure sets an environment variable to turn off linking against all deplibs. I'm willing to accept changes that would make enabling this for Debian builds an easy O(1) operation (i.e., not changes in every package, although that would actually be The Right Thing[3]). And then we change link_all_deplibs to linker_needs_all_deplibs and set that to no for any instance of GNU ld, but we also either - disregard it for cross-compilation, or, even better - walk the dependency tree manually for cross-compilation Please. link_all_deplibs=no on Debian has cost us several support mails, and false accusations and lost credibility in GNU Libtool. > And now I'd like to reduce it even more. > What an other problem is that in case of convience libraries, it > also adds all the libraries in the dependency_libs to the > depends, and so links with all of those. It should however only > link with those they tried to link the convience library with, > and not all it's dependency. I don't understand. Please post an example that exposes this change. > The best solution I can see for this is to only have the > libraries that were on the command line end up in the > dependency_libs on the .la file, atleast for convience libraries. > > I've been experimenting a little with this, and it seems to be > giving very good results so far. I need an example to be able to even understand the problem. > An other problem we've expierenced in the past is that in case we > remove some lib in the chain, all libraries that got (inderectly) > linked to it needed to be rebuild to remove the library from their > dependency_libs in their .la files. Having all the libraries you > need to link to in the .la file is really not a good idea in my > opinion. I think this should work recursivly, and find the other > libraries it should link to from the .la files it references. Huh? If you use symbols from it, you should link against it -- otherwise an incompatible update of the library will leave you with possibly subtle breakage at execution time. And if you don't use the library directly, then your link_all_deplibs=no should prevent linkage against it (unless I am missing something). If libtool decides to link against a library, I see no reason why that deplibs should not show up in dependency_libs. Maybe I am misunderstanding you again. > So, I've tried what the effect is of having only things you link > to in the dependency_libs of the .la file. And it already seems > to be working recursivly, so I have to wonder why they're all > there. Are there any plans on changing that behaviour soon? Again, please show with an example of how it behaves before/after the patch. > I've all been testing this with 1.5, and have no idea how HEAD or > something is doing this. > > I've attached a patch that "works for me". I'm not even sure > this is the proper way to do what I want, it just seems to have > the effect that I want. I would welcome some comment on it. What systems have you tested on? To be honest, any change to the dependency algorithm needs, to be able to go in, test exposure on at least, GNU/Linux w32 Darwin AIX with and without runtimelinking and ideally some other systems as well, in order to cover the various differences in link editor and runtime linker hardcoding behavior. And yes, given time I am certainly very willing to help, and I can test a lot, too. After 2.0 is out. Note we also know of a couple of open bugs in the current code that do not have to do with link_all_deplibs=no. They should probably be fixed first. > Do you think this can break something? Yes. Very certainly the patch below can and will break something. I mean, it's even unconditionally for any architecture. No Go. > Is there a better way to solve those problems? Dunno yet: need more information. Cheers, Ralf > --- ltmain.in.old 2005-12-05 00:45:03.000000000 +0100 > +++ ltmain.in 2005-12-05 00:10:32.000000000 +0100 > @@ -2762,7 +2762,7 @@ > # ... and its dependency_libs > tmp_libs= > for deplib in $dependency_libs; do > - newdependency_libs="$deplib $newdependency_libs" > +# newdependency_libs="$deplib $newdependency_libs" > if test "X$duplicate_deps" = "Xyes" ; then > case "$tmp_libs " in > *" $deplib "*) specialdeplibs="$specialdeplibs $deplib" ;; [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297726 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320698 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
