Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote: On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to That will make it impossible to support static linking against libraries which do not themselves provide .la files. We cannot do this upstream. I don't see how it's different than what we have now. If I understand what you're trying to say is: - The lib we're making now, liba, links to libb - libb itself does not have a .la file - to link to libb staticly, you also need to link to other libraries. Either you provided libb's depedencies when linking liba or not, what is going to be in liba.la is going to be the same. And if you really want static linking to work properly, you need some way to find out what libraries libb requires, be that with a libb.la or libb.pc file. and Ralf is pointing out that by trimming dependency_libs, you're breaking libb.la when linking libb statically via libtool. if there is no libb.la, then the issue is irrelevant because we arent talking about libtool scripts. - mike You mean that if liba.la was created when there was a libb.la that did contain the needed info? In that case trying to use liba.la now already fails, because it's looking for libb.la. In case liba.la never knew about a libb.la, or libb.a never existed, I can't see any difference. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
libxcb version 1.0 installed: /usr/lib/libxcb-xlib.la /usr/lib/libxcb-xlib.so /usr/lib/libxcb-xlib.so.0 /usr/lib/libxcb-xlib.so.0.0.0 However, libxcb version 1.4 did not install the above mentioned files. libX11 version 1.1.3 linked using /usr/lib/libxcb-xlib.la. All software linked with libX11 by using the information provided in libX11.la also links with libxcb-xlib Consequently, that software, if it is a library, also installs libtool archive files that contained a reference to /usr/lib/libxcb-xlib.la However, installed software that does not directly use libxcb-xlib does not need to be explicitly linked with libxcb-xlib. If such software was linked with libX11 and libX11 was linked with libxcb-xlib then the libxcb-xlib library would also be loaded when libX11 is loaded. The software that links with libX11 does not have a need to know about libxcb-xlib as long as libX11 was correctly linked. The important question is, Why does it matter? In order to correct this problem following the update of libxcb from version 1.0 to version 1.4 the only software that should be required to recompile is libX11. However, due to much installed software be linked with the now missing libxcb-xlib library and also the many .la files that reference libxcb-xlib.la all those software projects must also be recompiled, relinked, and reinstalled. That will amount to over 100 software projects on some boxes. This is a real example of something that is really happening and not a hypothetical libA libB conjecture. I hope the elaboration would demystify one of the more troublesome aspects about libtool. While I prefer to not do all that compiling, merely sediting libtool archive files will not solve the problem. Fortunately, I use a distribution that automatically detects and corrects problems due to library updates. Consequently, I am care free. However, if I used a pre-compiled binary based distro then I would instead be downloading hundreds of replacement packages instead of merely recompiling sources that my boxes previously acquired. Something like that might give maintainers of a pre-compiled binary based distro cause to carefully reconsider both the use and content of libtool archive files, because such changes could avoid a +100 megabyte download update. I agree that this topic of conversation is worthy of the libtool mail list and should not be confined to a distribution's email list. From one point of view this type of problem is caused due to something libtool is doing rather than something that distribution maintainers and software authors are intentionally doing. Furthermore, I do not know the situation with Debian maintainers. I do not care if anything is done about this type of problem. However, if I deployed a pre-compiled binary based distro then I would probably have an opinion. Yet it would seem that if this is a problem worthy of being fixed then it should be fixed by libtool authors instead of the maintainers of pre-compiled binary distribution. I apologize if the information that I provided is not congruent with the subject. As I wrote above I do not what Debian maintainers are doing nor why. However, if I were to make a wild guess then I would speculate that an update such as the one I described above might be sufficient to provoke the ire of Debian maintainers. On Tue, Sep 1, 2009 at 9:33 AM, Kurt Roeckxk...@roeckx.be wrote: On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote: On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to That will make it impossible to support static linking against libraries which do not themselves provide .la files. We cannot do this upstream. I don't see how it's different than what we have now. If I understand what you're trying to say is: - The lib we're making now, liba, links to libb - libb itself does not have a .la file - to link to libb staticly, you also need to link to other libraries. Either you provided libb's depedencies when linking liba or not, what is going to be in liba.la is going to be the same. And if you really want static linking to work properly, you need some way to find out what libraries libb requires, be that with a libb.la or libb.pc file. and Ralf is pointing out that by trimming dependency_libs, you're breaking libb.la when linking libb statically via libtool. if there is no libb.la, then the issue is irrelevant because we arent talking about libtool scripts. - mike You mean that if liba.la was created when there was a libb.la that did contain the needed info? In that case trying to use liba.la now already fails, because it's looking for libb.la. In
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tuesday 01 September 2009 12:33:09 Kurt Roeckx wrote: On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote: On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to That will make it impossible to support static linking against libraries which do not themselves provide .la files. We cannot do this upstream. I don't see how it's different than what we have now. If I understand what you're trying to say is: - The lib we're making now, liba, links to libb - libb itself does not have a .la file - to link to libb staticly, you also need to link to other libraries. Either you provided libb's depedencies when linking liba or not, what is going to be in liba.la is going to be the same. And if you really want static linking to work properly, you need some way to find out what libraries libb requires, be that with a libb.la or libb.pc file. and Ralf is pointing out that by trimming dependency_libs, you're breaking libb.la when linking libb statically via libtool. if there is no libb.la, then the issue is irrelevant because we arent talking about libtool scripts. You mean that if liba.la was created when there was a libb.la that did contain the needed info? In that case trying to use liba.la now already fails, because it's looking for libb.la. if you delete .la files that were recorded already in other .la files and dont clean up the mess, then that's a fault in your process In case liba.la never knew about a libb.la, or libb.a never existed, I can't see any difference. if libb.la didnt exist, then this discussion is completely irrelevant because you're no longer talking about libtool -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Hello Kurt, * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to That will make it impossible to support static linking against libraries which do not themselves provide .la files. We cannot do this upstream. - Libtool should recursively read all the .la files in the .la file. Again, this implies that all libraries of interest provide .la files. But Debian itself contributes to making that assumption be false. Besides, another issue that we currently have, and whose effect would be worsened by this change, is that deplib searches in staging directories need to take the staging prefix into account. With that change only one .la file would need to be updated. Well, for that you do not need that the .la file only contains the libraries the current library links to. What you need is the following. Assuming there is a deplibs and a private_deplibs (for static linking). Then, when your dependency walker is smart enough (and correct) to recurse .la files, then you can omit references to .la files which you only link against indirectly. However, references to indirect non-libtool deplibs still need to be added to private_deplibs. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: Hello Kurt, * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to That will make it impossible to support static linking against libraries which do not themselves provide .la files. We cannot do this upstream. I don't see how it's different than what we have now. If I understand what you're trying to say is: - The lib we're making now, liba, links to libb - libb itself does not have a .la file - to link to libb staticly, you also need to link to other libraries. Either you provided libb's depedencies when linking liba or not, what is going to be in liba.la is going to be the same. And if you really want static linking to work properly, you need some way to find out what libraries libb requires, be that with a libb.la or libb.pc file. - Libtool should recursively read all the .la files in the .la file. Again, this implies that all libraries of interest provide .la files. But Debian itself contributes to making that assumption be false. And the main reason Debian currently doesn't want to ship .la files is because they currently cause more problems than they solve. We want to link as much as possible shared. But it would be nice if we could make it easier for our users to link something staticly if they want to do that. Besides, another issue that we currently have, and whose effect would be worsened by this change, is that deplib searches in staging directories need to take the staging prefix into account. I'm not sure I really understand your point here. But I think it has to do with finding the right library at link time, and that it makes things harder. It's not because it's harder that we shouldn't be doing it. With that change only one .la file would need to be updated. Well, for that you do not need that the .la file only contains the libraries the current library links to. What you need is the following. Assuming there is a deplibs and a private_deplibs (for static linking). Then, when your dependency walker is smart enough (and correct) to recurse .la files, then you can omit references to .la files which you only link against indirectly. However, references to indirect non-libtool deplibs still need to be added to private_deplibs. So you're saying that for the example above, you want to specify libb's depedencies, and make them end up in liba.la's private_deplibs, and that private_deplibs should only be used for cases where the libraries we're linking to do not provide the dependency info? Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to That will make it impossible to support static linking against libraries which do not themselves provide .la files. We cannot do this upstream. I don't see how it's different than what we have now. If I understand what you're trying to say is: - The lib we're making now, liba, links to libb - libb itself does not have a .la file - to link to libb staticly, you also need to link to other libraries. Either you provided libb's depedencies when linking liba or not, what is going to be in liba.la is going to be the same. And if you really want static linking to work properly, you need some way to find out what libraries libb requires, be that with a libb.la or libb.pc file. and Ralf is pointing out that by trimming dependency_libs, you're breaking libb.la when linking libb statically via libtool. if there is no libb.la, then the issue is irrelevant because we arent talking about libtool scripts. - mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tue, Aug 25, 2009 at 05:46:12PM +0300, Anssi Hannula wrote: dependency_libs contains the dependencies of a library. These are needed when linking statically. These are also needed when linking dynamically, but only on certain systems (they are not needed on normal linux systems). I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Debian already ships a version that has link_all_deplibs set to no, which already solves _some_ of the problems we have. (It also has it's issues.) The reason we still have a problem is that the .la file contains all the shared files that this lib, and recursively all the libs they depends on, link to. And when somewhere in the chain something no longer links to a library we have to go and fix all the libraries in between to get rid of the broken .la files. So it currently seems to be easier to ship .la files with dependency_libs set to an empty string. I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to - Libtool should recursively read all the .la files in the .la file. With that change only one .la file would need to be updated. I have an implementation (in C) that does this. And it atleast finds some issues in the test suite that I've mailed about and didn't get resolved yet. I should probably also keep working on my version. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Wed, Aug 26, 2009 at 05:01:18AM CEST: Is someone here willing to contribute a portable m4 macro which tests the compiler (and/or linker) to prove beyond a shadow of a doubt that it adequately supports the implicit linkage required? The tests should work for more than Linux and should be based on observed behavior. Is support in Debian full now? I'm not sure what you mean by this. Do dlopen'ed modules that have indirect dependencies outside of default-searched library paths get loaded correctly now, with DT_RPATH entries only pointing to direct deplibs (and recursively for their DT_RPATH entries)? This works fine without linking in dependency_libs. I continue the test from my earlier message: $ cd ../enchant-1.4.2 $ ./configure --prefix=/home/anssi/odd/usr \ --libdir=/home/anssi/odd/usr/lib \ LDFLAGS=-L/home/anssi/odd/usr/lib \ CPPFLAGS=-I/home/anssi/odd/usr/include $ make make install $ sed -i s,^dependency_libs=.*$,dependency_libs='', \ /home/anssi/odd/usr/lib/libenchant.la \ /home/anssi/odd/usr/lib/enchant/libenchant_*.la $ /home/anssi/odd/usr/bin/enchant-lsmod | grep voikko voikko (Voikko Provider) $ objdump -p /home/anssi/odd/usr/lib/enchant/libenchant_voikko.so | grep -e NEEDED.*voik -e RPA NEEDED libvoikko.so.1 RPATH/home/anssi/odd/usr/lib $ objdump -p /home/anssi/odd/usr/lib/libvoikko.so.1 | grep -e malaga -e RPATH NEEDED libmalaga.so.7 RPATH/home/anssi/odd/lib $ ls /home/anssi/odd/lib/libmalaga.so.7 /home/anssi/odd/lib/libmalaga.so.7@ So when enchant dlopens libenchant_voikko.so, the dependency on libvoikko.so.1 and in turn its dependency on libmalaga.so.7 in another directory are resolved fine. Support for indirect dependencies should be a configure option so that it should be specifically requested. See $link_all_deplibs (which is no on Debian but yes in FSF Libtool). IIRC link_all_deplibs only affects executables, not libraries. The comment describing link_all_deplibs seems to agree: # Whether libtool must link a program against all its dependency libraries. -- Anssi Hannula ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Paul Wise wrote: On Tue, 2009-08-25 at 18:34 +0300, Anssi Hannula wrote: You mean to subscribe on the debian development list? I'd think this list would be the more appropriate place for discussing a proper upstream solution. There is no need to subscribe, just ask people to CC you. I'm unsure if you'll get useful feedback from Debian without posting to debian-devel. Hmm, it seems to me like there is some confusion; I'm not a libtool upstream developer, I just want an upstream solution to this problem just as Debian people do (and most likely other distros; I see Fedora also removes .la files per policy). Or maybe your suggestion was not directed to me. In that case, the confusion is all mine :) -- Anssi Hannula ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Wed, 26 Aug 2009, Ralf Wildenhues wrote: Linux does seem to have good dynamic linker support and its a shame libtool effectively drags it down to a lower common denominator of other platforms with worse support. Actually, historically that was probably done on purpose, to remind developers that they wouldn't have the same power available everywhere (which can help avoid relying on nonportable features). (I'm not stating my own opinion here.) It is indeed true that since many packages are primarily developed under Linux using shared libraries and since Linux offers up dependencies automatically, then many packages will fail to compile on operating systems which don't do that. The problem is really more cultural/social/political (i.e. No need to test on anything but GNU Linux) than technical. Since Linux is already offering up dependencies automatically (and also deleting the .la files), the problem already exists, and porters commonly need to deal with it. Given the current situation, it seems correct that Linux should be more equal than the others. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
* Anssi Hannula wrote on Wed, Aug 26, 2009 at 12:05:22PM CEST:
Ralf Wildenhues wrote:
* Bob Friesenhahn wrote on Wed, Aug 26, 2009 at 05:01:18AM CEST:
Is someone here willing to contribute a portable m4 macro which
tests the compiler (and/or linker) to prove beyond a shadow of a
doubt that it adequately supports the implicit linkage required? The
tests should work for more than Linux and should be based on
observed behavior.
Is support in Debian full now?
I'm not sure what you mean by this.
Well, my message certainly was terse; what I meant was whether the
following scenario now works:
Do dlopen'ed modules that have indirect
dependencies outside of default-searched library paths get loaded
correctly now, with DT_RPATH entries only pointing to direct deplibs
(and recursively for their DT_RPATH entries)?
This works fine without linking in dependency_libs. I continue the test
from my earlier message:
What I would like to see is this test (written without using libtool,
sorry, I haven't gone through your test):
cd /tmp
mkdir a a/c b main
cd a/c
echo 'int c () { return 0; }' c.c
gcc -shared -fPIC -o libcee.so.0 c.c -Wl,-soname,libcee.so.0
ln -s libcee.so.0 libcee.so
cd ..
echo 'extern int c (); int a () { return c (); }' a.c
gcc -shared -fPIC -o liba.so.0 a.c -Wl,-soname,liba.so.0 -Lc -lcee \
-Wl,-rpath,c
ln -s liba.so.0 liba.so
cd ../b
echo 'extern int a (); int b () { return a (); }' b.c
gcc -shared -fPIC -o b.so b.c -Wl,-rpath,../a -L../a -la
cd ../main
cat main.c \EOF
#include stdio.h
#include stdlib.h
#include dlfcn.h
int main ()
{
void *handle;
int (*p)(void);
char *error;
handle = dlopen(b.so, RTLD_LAZY);
if (!handle) {
fprintf(stderr, %s\n, dlerror());
exit(EXIT_FAILURE);
}
dlerror();/* Clear any existing error */
*(void **) (p) = dlsym(handle, b);
if ((error = dlerror()) != NULL) {
fprintf(stderr, %s\n, error);
exit(EXIT_FAILURE);
}
printf(%d\n, (*p)());
dlclose(handle);
exit(EXIT_SUCCESS);
}
EOF
gcc -o main main.c -ldl
LD_LIBRARY_PATH=../b ./main
And trying that out now, I see that while this doesn't work, it works as
soon as you replace
-Wl,-rpath,c
with
-Wl,-rpath,`pwd`/c
in the line creating liba.so.0. Nice.
So when enchant dlopens libenchant_voikko.so, the dependency on
libvoikko.so.1 and in turn its dependency on libmalaga.so.7 in another
directory are resolved fine.
Yep; seems your test was similar.
Support for indirect dependencies should be a configure option so
that it should be specifically requested.
See $link_all_deplibs (which is no on Debian but yes in FSF
Libtool).
IIRC link_all_deplibs only affects executables, not libraries.
The comment describing link_all_deplibs seems to agree:
# Whether libtool must link a program against all its dependency libraries.
The code in ltmain.sh doesn't agree, however. And IIUC then Debian
wouldn't want libraries to link against their indirect deplibs either,
as that would still make the problem set too big for them.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Paul Wise wrote: Just so you know, Debian is removing all .la files where possible or emptying dependency_libs where not possible: http://lists.debian.org/debian-devel/2009/08/msg00783.html http://lists.debian.org/debian-release/2009/08/threads.html#00217 http://lists.debian.org/debian-devel/2009/08/thrd2.html#00783 Would it be possible to implement dependency_libs_shared or similar in libtool? More information about this idea is here: http://lists.debian.org/debian-release/2009/08/msg00218.html This would allow static linking to continue, but also remove many unneeded dependencies. I don't understand what the proposed dependency_libs_shared would be for. dependency_libs contains the dependencies of a library. These are needed when linking statically. These are also needed when linking dynamically, but only on certain systems (they are not needed on normal linux systems). I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. -- Anssi Hannula ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tue, 2009-08-25 at 17:46 +0300, Anssi Hannula wrote: I don't understand what the proposed dependency_libs_shared would be for. dependency_libs contains the dependencies of a library. These are needed when linking statically. These are also needed when linking dynamically, but only on certain systems (they are not needed on normal linux systems). I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. I don't know enough about the issue, nor the reason why pkgconfig has both Libs.private/Requires.private and Libs/Requires. I would suggest you post in the thread asking what the proper upstream solution would look like. People who are more knowledgeable are likely to answer any questions you have. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tue, 25 Aug 2009, Anssi Hannula wrote: I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Paul Wise wrote: On Tue, 2009-08-25 at 17:46 +0300, Anssi Hannula wrote: I don't understand what the proposed dependency_libs_shared would be for. dependency_libs contains the dependencies of a library. These are needed when linking statically. These are also needed when linking dynamically, but only on certain systems (they are not needed on normal linux systems). I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. I don't know enough about the issue, nor the reason why pkgconfig has both Libs.private/Requires.private and Libs/Requires. AFAICS Libs.private is pretty much equivalent to dependency_libs. I would suggest you post in the thread asking what the proper upstream solution would look like. People who are more knowledgeable are likely to answer any questions you have. You mean to subscribe on the debian development list? I'd think this list would be the more appropriate place for discussing a proper upstream solution. -- Anssi Hannula ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tuesday 25 August 2009 11:17:49 Bob Friesenhahn wrote: On Tue, 25 Aug 2009, Anssi Hannula wrote: I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. why ? -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tue, 2009-08-25 at 18:34 +0300, Anssi Hannula wrote: You mean to subscribe on the debian development list? I'd think this list would be the more appropriate place for discussing a proper upstream solution. There is no need to subscribe, just ask people to CC you. I'm unsure if you'll get useful feedback from Debian without posting to debian-devel. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Mike wrote: On Tuesday 25 August 2009 12:42:19 Bob Friesenhahn wrote: On Tue, 25 Aug 2009, Mike Frysinger wrote: Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. why ? When viewing the issue through Linux package-maintainer spectacles everything looks pretty straightforward since the environment and packages are well managed and tested prior to deployment. Any failures can be usefully corrected. Libraries are carefully built with well-managed partial dependency lists. If you consider the case where someone installs and builds everything from a random collection of source packages on a random Linux release, then the situation is different. This issue has some up oodles of times. Obviously there is a good reason for the complaints (Linux equivalent of DLL hell) but the solution in libtool needs to be assured to work everywhere, and not just on well-managed well-manicured recent Linux. the dll hell issue you refer to really doesnt have much (anything?) to do with libtool. that's a binary package issue. making the code use reduced library sets for only linux targets is fine by me. libtool already has plenty of target-specific code based on the quality of library handling. I think the scope of the problem is more devious than you imagine. Example: - install libA to /odd/lib/libA.so - configure libB with /odd/lib/libA.so - install libB to /odd/usr/lib/libB.so - configure App with libB in /odd/usr/lib/libB.so - compilation of App fails since the linker can't find libA.so Libtool's dependency lists would have told the linker where libA was installed. Many people follow this sort of pattern on shared filesystems. Later, Daniel ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Hello, * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST: On Tue, 25 Aug 2009, Anssi Hannula wrote: I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. With GNU/Linux, and libraries all being in directories searched by default by both the link editor and the runtime linker, the problems are fairly limited. IIRC Debian requires that you link directly against all libraries that you require directly. The problems start as soon as you link (directly or indirectly) against libraries in directories not searched by default. IOW: typically anything not provided by a properly packaged Debian package, installed by the user or the system maintainer. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tuesday 25 August 2009 13:50:18 dherr...@tentpost.com wrote: Mike wrote: On Tuesday 25 August 2009 12:42:19 Bob Friesenhahn wrote: On Tue, 25 Aug 2009, Mike Frysinger wrote: Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. why ? When viewing the issue through Linux package-maintainer spectacles everything looks pretty straightforward since the environment and packages are well managed and tested prior to deployment. Any failures can be usefully corrected. Libraries are carefully built with well-managed partial dependency lists. If you consider the case where someone installs and builds everything from a random collection of source packages on a random Linux release, then the situation is different. This issue has some up oodles of times. Obviously there is a good reason for the complaints (Linux equivalent of DLL hell) but the solution in libtool needs to be assured to work everywhere, and not just on well-managed well-manicured recent Linux. the dll hell issue you refer to really doesnt have much (anything?) to do with libtool. that's a binary package issue. making the code use reduced library sets for only linux targets is fine by me. libtool already has plenty of target-specific code based on the quality of library handling. I think the scope of the problem is more devious than you imagine. Example: - install libA to /odd/lib/libA.so - configure libB with /odd/lib/libA.so - install libB to /odd/usr/lib/libB.so - configure App with libB in /odd/usr/lib/libB.so - compilation of App fails since the linker can't find libA.so Libtool's dependency lists would have told the linker where libA was installed. Many people follow this sort of pattern on shared filesystems. having libtool process the libdir= fields and add appropriate -rpath-link options is trivial to do. that doesnt mean every library in the dependency list should be added to the final linking step. -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: On Tue, 25 Aug 2009, Anssi Hannula wrote: I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. Relying on the dynamic linker to resolve implicit dependencies is the only way that it's really feasible to maintain a distribution the size of Debian. Otherwise, your shared library dependencies get so entangled that it's extremely difficult to correctly handle transitions. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tue, 25 Aug 2009, Russ Allbery wrote: Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. Relying on the dynamic linker to resolve implicit dependencies is the only way that it's really feasible to maintain a distribution the size of Debian. Otherwise, your shared library dependencies get so entangled that it's extremely difficult to correctly handle transitions. Note that program/library linkage and the dynamic linker are two entirely different things. Libtool only takes care of the former, although it may run ldconfig to assist with the latter. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tue, 25 Aug 2009, Russ Allbery wrote: I know what the difference is. My point is that adding an explicit dependency on a shared library whose ABI you do not use directly simply doesn't scale when maintaining a distribution the size of Debian. You have to rely on the dynamic linker to resolve transitive dependencies. I mention the dynamic linker because one of the reasons why libtool has this feature is for platforms where the dynamic linker *cannot* resolve transitive dependencies and needs the binary to be linked against all shared libraries, including ones only used indirectly. How would you like to deal with the case where a library has multiple usable dependencies, which satisify identical purposes, but via different possible libraries? libfoo-ssl_fast.so myprog -- somelib -- or libfoo-ssl_slow.so Note that in this case myprog depends on somelib and so that is an explicit dependency. However somelib needs some symbols from a library that the user selects at link time. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: On Tue, 25 Aug 2009, Russ Allbery wrote: Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. Relying on the dynamic linker to resolve implicit dependencies is the only way that it's really feasible to maintain a distribution the size of Debian. Otherwise, your shared library dependencies get so entangled that it's extremely difficult to correctly handle transitions. Note that program/library linkage and the dynamic linker are two entirely different things. Libtool only takes care of the former, although it may run ldconfig to assist with the latter. I know what the difference is. My point is that adding an explicit dependency on a shared library whose ABI you do not use directly simply doesn't scale when maintaining a distribution the size of Debian. You have to rely on the dynamic linker to resolve transitive dependencies. I mention the dynamic linker because one of the reasons why libtool has this feature is for platforms where the dynamic linker *cannot* resolve transitive dependencies and needs the binary to be linked against all shared libraries, including ones only used indirectly. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: How would you like to deal with the case where a library has multiple usable dependencies, which satisify identical purposes, but via different possible libraries? libfoo-ssl_fast.so myprog -- somelib -- or libfoo-ssl_slow.so Note that in this case myprog depends on somelib and so that is an explicit dependency. However somelib needs some symbols from a library that the user selects at link time. In this one particular case, an explicit dependency seems reasonable. This case is exceptionally rare. In all the years that I've worked on free software and packaging of software for multiple different versions of UNIX, I've never wanted to do this, and I don't know of any case in the thousands of packages in Debian where this technique is used. Normally it's easier and more robust to just build two different versions of somelib, one for each of the alternative dependency libraries. (See, for instance, how cURL is handled in Debian.) -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST: On Tue, 25 Aug 2009, Anssi Hannula wrote: I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. With GNU/Linux, and libraries all being in directories searched by default by both the link editor and the runtime linker, the problems are fairly limited. IIRC Debian requires that you link directly against all libraries that you require directly. The problems start as soon as you link (directly or indirectly) against libraries in directories not searched by default. IOW: typically anything not provided by a properly packaged Debian package, installed by the user or the system maintainer. Surely at least on Linux the -rpath linker option would be a much better way to solve this? Linux does seem to have good dynamic linker support and its a shame libtool effectively drags it down to a lower common denominator of other platforms with worse support. Cheers, Richard -- Richard Purdie Intel Open Source Technology Centre ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tuesday 25 August 2009 18:41:52 Russ Allbery wrote: Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: How would you like to deal with the case where a library has multiple usable dependencies, which satisify identical purposes, but via different possible libraries? libfoo-ssl_fast.so myprog -- somelib -- or libfoo-ssl_slow.so Note that in this case myprog depends on somelib and so that is an explicit dependency. However somelib needs some symbols from a library that the user selects at link time. In this one particular case, an explicit dependency seems reasonable. This case is exceptionally rare. In all the years that I've worked on free software and packaging of software for multiple different versions of UNIX, I've never wanted to do this, and I don't know of any case in the thousands of packages in Debian where this technique is used. Normally it's easier and more robust to just build two different versions of somelib, one for each of the alternative dependency libraries. (See, for instance, how cURL is handled in Debian.) i dont really see how this case is related to the discussion at hand. if a library maker wanted to let people pick a provider, then the dependency wouldnt be expressed in the libtool linker script. whether libtool processes all of the libraries in the linker script is irrelevant to this issue. the termcap library is the only real world example ive seen, but Debian and pretty much every distro that matters forces ncurses everywhere. you can see this with really old distros where readline never linked with a termcap provider -- packages that wanted to use readline had to select the library itself. that's why you'll some configure scripts that try -lreadline and if that fails, does a search with like -lncurses, -lcurses, and -ltermcap. -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote: On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST: On Tue, 25 Aug 2009, Anssi Hannula wrote: I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. With GNU/Linux, and libraries all being in directories searched by default by both the link editor and the runtime linker, the problems are fairly limited. IIRC Debian requires that you link directly against all libraries that you require directly. The problems start as soon as you link (directly or indirectly) against libraries in directories not searched by default. IOW: typically anything not provided by a properly packaged Debian package, installed by the user or the system maintainer. Surely at least on Linux the -rpath linker option would be a much better way to solve this? a combo of -rpath and -rpath-link ... -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
dherr...@tentpost.com wrote: Mike wrote: making the code use reduced library sets for only linux targets is fine by me. libtool already has plenty of target-specific code based on the quality of library handling. I think the scope of the problem is more devious than you imagine. Example: - install libA to /odd/lib/libA.so - configure libB with /odd/lib/libA.so - install libB to /odd/usr/lib/libB.so - configure App with libB in /odd/usr/lib/libB.so - compilation of App fails since the linker can't find libA.so Libtool's dependency lists would have told the linker where libA was installed. Many people follow this sort of pattern on shared filesystems. rpath tells that as well, and libtool adds it automatically when installing to a non-standard path. I tested the above: $ cd malaga-7.12 $ ./configure --prefix=/home/anssi/odd --libdir=/home/anssi/odd/lib $ make make install $ sed -i s,^dependency_libs=.*$,dependency_libs='', \ /home/anssi/odd/lib/libmalaga.la $ cd ../libvoikko-2.0 $ ./configure --prefix=/home/anssi/odd/usr \ --libdir=/home/anssi/odd/usr/lib LDFLAGS=-L/home/anssi/odd/lib \ CPPFLAGS=-I/home/anssi/odd/include $ make make install $ sed -i s,^dependency_libs=.*$,dependency_libs='', \ /home/anssi/odd/usr/lib/libvoikko.la $ cd ../tmispell-voikko-0.7.1 $ ./configure --prefix=/home/anssi/odd/usr \ --libdir=/home/anssi/odd/usr/lib \ LDFLAGS=-L/home/anssi/odd/usr/lib \ CPPFLAGS=-I/home/anssi/odd/usr/include $ make make install Compilation worked fine. The program also works correctly: $ /home/anssi/odd/usr/bin/tmispell --help | head -n1 Usage: tmispell-voikko [options] [file]... This is because libtool automatically sets the RPATH correctly in the binary and the libraries: $ objdump -p /home/anssi/odd/usr/bin/tmispell | grep -e voikko -e RPATH NEEDED libvoikko.so.1 RPATH/home/anssi/odd/usr/lib $ objdump -p /home/anssi/odd/usr/lib/libvoikko.so.1 | grep -e malaga -e RPATH NEEDED libmalaga.so.7 RPATH/home/anssi/odd/lib -- Anssi Hannula ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Mike Frysinger wrote: On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote: On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST: On Tue, 25 Aug 2009, Anssi Hannula wrote: I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. With GNU/Linux, and libraries all being in directories searched by default by both the link editor and the runtime linker, the problems are fairly limited. IIRC Debian requires that you link directly against all libraries that you require directly. The problems start as soon as you link (directly or indirectly) against libraries in directories not searched by default. IOW: typically anything not provided by a properly packaged Debian package, installed by the user or the system maintainer. Surely at least on Linux the -rpath linker option would be a much better way to solve this? a combo of -rpath and -rpath-link ... Well, -rpath is already added by libtool when a dependency is not in the standard library search path. AFAICS -rpath-link would be useful if we want to be double-sure that it works, e.g. in case RPATH of a library/app has been tampered with. I'm not taking a stance on whether -rpath-link should be added or not, though. -- Anssi Hannula ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tuesday 25 August 2009 20:33:25 Anssi Hannula wrote: Mike Frysinger wrote: On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote: On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST: On Tue, 25 Aug 2009, Anssi Hannula wrote: I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. With GNU/Linux, and libraries all being in directories searched by default by both the link editor and the runtime linker, the problems are fairly limited. IIRC Debian requires that you link directly against all libraries that you require directly. The problems start as soon as you link (directly or indirectly) against libraries in directories not searched by default. IOW: typically anything not provided by a properly packaged Debian package, installed by the user or the system maintainer. Surely at least on Linux the -rpath linker option would be a much better way to solve this? a combo of -rpath and -rpath-link ... Well, -rpath is already added by libtool when a dependency is not in the standard library search path. AFAICS -rpath-link would be useful if we want to be double-sure that it works, e.g. in case RPATH of a library/app has been tampered with. I'm not taking a stance on whether -rpath-link should be added or not, though. i'm thinking in terms of linker -rpath/-rpath-link, not libtool (i vaguely recall they're similar but not the same). we want to avoid rpath's being encoded in binaries for system library paths. -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Mike Frysinger wrote: On Tuesday 25 August 2009 20:33:25 Anssi Hannula wrote: Mike Frysinger wrote: On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote: On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST: On Tue, 25 Aug 2009, Anssi Hannula wrote: I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Relying on the OS's implicit dependency features seems to be an approach which is fraught with peril. With GNU/Linux, and libraries all being in directories searched by default by both the link editor and the runtime linker, the problems are fairly limited. IIRC Debian requires that you link directly against all libraries that you require directly. The problems start as soon as you link (directly or indirectly) against libraries in directories not searched by default. IOW: typically anything not provided by a properly packaged Debian package, installed by the user or the system maintainer. Surely at least on Linux the -rpath linker option would be a much better way to solve this? a combo of -rpath and -rpath-link ... Well, -rpath is already added by libtool when a dependency is not in the standard library search path. AFAICS -rpath-link would be useful if we want to be double-sure that it works, e.g. in case RPATH of a library/app has been tampered with. I'm not taking a stance on whether -rpath-link should be added or not, though. i'm thinking in terms of linker -rpath/-rpath-link, not libtool (i vaguely recall they're similar but not the same). So am I. we want to avoid rpath's being encoded in binaries for system library paths. Yes, we do. And as I said above, that is what libtool currently does. It adds -rpath (the linker one) automatically, but only for non-system paths. -- Anssi Hannula ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Is someone here willing to contribute a portable m4 macro which tests the compiler (and/or linker) to prove beyond a shadow of a doubt that it adequately supports the implicit linkage required? The tests should work for more than Linux and should be based on observed behavior. Support for indirect dependencies should be a configure option so that it should be specifically requested. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
* Russ Allbery wrote on Wed, Aug 26, 2009 at 12:41:52AM CEST: Bob Friesenhahn writes: libfoo-ssl_fast.so myprog -- somelib -- or libfoo-ssl_slow.so This case is exceptionally rare. It used to be a lot more common, and likely still is somewhat common, in the HPC community. You have several BLAS libraries to choose from, several higher-level ones, too. Of course, by now they aren't really binary compatible any more at all, so it makes this less possible. In all the years that I've worked on free software and packaging of software for multiple different versions of UNIX, I've never wanted to do this, and I don't know of any case in the thousands of packages in Debian where this technique is used. That was probably a conscious decision. Normally it's easier and more robust to just build two different versions of somelib, one for each of the alternative dependency libraries. (See, for instance, how cURL is handled in Debian.) So you end up with libfancyalgo-atlas-openmpi-devel and similar packages. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
* Bob Friesenhahn wrote on Wed, Aug 26, 2009 at 05:01:18AM CEST: Is someone here willing to contribute a portable m4 macro which tests the compiler (and/or linker) to prove beyond a shadow of a doubt that it adequately supports the implicit linkage required? The tests should work for more than Linux and should be based on observed behavior. Is support in Debian full now? Do dlopen'ed modules that have indirect dependencies outside of default-searched library paths get loaded correctly now, with DT_RPATH entries only pointing to direct deplibs (and recursively for their DT_RPATH entries)? Support for indirect dependencies should be a configure option so that it should be specifically requested. See $link_all_deplibs (which is no on Debian but yes in FSF Libtool). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
* Richard Purdie wrote on Wed, Aug 26, 2009 at 12:37:54AM CEST: On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote: With GNU/Linux, and libraries all being in directories searched by default by both the link editor and the runtime linker, the problems are fairly limited. IIRC Debian requires that you link directly against all libraries that you require directly. The problems start as soon as you link (directly or indirectly) against libraries in directories not searched by default. IOW: typically anything not provided by a properly packaged Debian package, installed by the user or the system maintainer. Surely at least on Linux the -rpath linker option would be a much better way to solve this? What do you mean with much better? Libtool uses -rpath to solve this. As Mike said, part of the issue is that libtool doesn't use -rpath-link. Linux does seem to have good dynamic linker support and its a shame libtool effectively drags it down to a lower common denominator of other platforms with worse support. Actually, historically that was probably done on purpose, to remind developers that they wouldn't have the same power available everywhere (which can help avoid relying on nonportable features). (I'm not stating my own opinion here.) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
* Mike Frysinger wrote on Wed, Aug 26, 2009 at 01:49:18AM CEST: On Tuesday 25 August 2009 18:41:52 Russ Allbery wrote: Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: libfoo-ssl_fast.so myprog -- somelib -- or libfoo-ssl_slow.so Note that in this case myprog depends on somelib and so that is an explicit dependency. However somelib needs some symbols from a library that the user selects at link time. i dont really see how this case is related to the discussion at hand. if a library maker wanted to let people pick a provider, then the dependency wouldnt be expressed in the libtool linker script. whether libtool processes all of the libraries in the linker script is irrelevant to this issue. That is not right. Well, the way you state it, it can only work on GNU/Linux and a couple of other systems, but not portably. For other systems libtool needs to know. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Bob Friesenhahn wrote on Wed, Aug 26, 2009 at 05:01:18AM CEST: Is someone here willing to contribute a portable m4 macro which tests the compiler (and/or linker) to prove beyond a shadow of a doubt that it adequately supports the implicit linkage required? The tests should work for more than Linux and should be based on observed behavior. Is support in Debian full now? Do dlopen'ed modules that have indirect dependencies outside of default-searched library paths get loaded correctly now, with DT_RPATH entries only pointing to direct deplibs (and recursively for their DT_RPATH entries)? This particular scenario I've not checked personally. I never use non-default-searched library paths for anything. I certainly agree that libtool needs to support that case, though. dlopened modules are something of a special case; it's one of the places where Debian may not remove *.la files depending on the specific situation. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ http://lists.gnu.org/mailman/listinfo/libtool
removal of .la files from Debian and a possible solution to the libtool shared libs problem
Hi, Just so you know, Debian is removing all .la files where possible or emptying dependency_libs where not possible: http://lists.debian.org/debian-devel/2009/08/msg00783.html http://lists.debian.org/debian-release/2009/08/threads.html#00217 http://lists.debian.org/debian-devel/2009/08/thrd2.html#00783 Would it be possible to implement dependency_libs_shared or similar in libtool? More information about this idea is here: http://lists.debian.org/debian-release/2009/08/msg00218.html This would allow static linking to continue, but also remove many unneeded dependencies. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
