Re: multilib support
Ralf Wildenhues wrote:
That is only half of the problem. If it were the only problem, then we
could just prepend all the lib64 paths on GNU/Linux, and the sparcv9
ones on Solaris. The other half is that libtool does not skip libraries
it finds there: deplibs_check_method is set to pass_all.
So the task is: find a good replacement for that which is both cheap and
accurate. And feasible.
Uhm, why is that a problem? If libtool did a check which ABI it's actually
compiling/linking for, it could always prepend the appropriate path, no?
This would of course only fix the -l case. It wouldn't work if *.{l,}a files are
specified directly. But IMHO, whatever is specifying the files directly has to
make sure it takes the right ones itself.
Only way I could think of to fix .la files would be to compare the output of
`file -L lib${name}.so` with they output of file on a little program we just
compile ourself. However, that would break if the .so file is not the library
itself but e.g. a ld script.
Only way to fix the .a files handling I can think of is unpacking it, calling
file on one of the files in it and comparing again, but that definitively sucks.
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 Developer
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: multilib support
On Fri, 31 Mar 2006, Simon Stelling wrote:
Ralf Wildenhues wrote:
That is only half of the problem. If it were the only problem, then we
could just prepend all the lib64 paths on GNU/Linux, and the sparcv9
ones on Solaris. The other half is that libtool does not skip libraries
it finds there: deplibs_check_method is set to pass_all.
So the task is: find a good replacement for that which is both cheap and
accurate. And feasible.
Uhm, why is that a problem? If libtool did a check which ABI it's actually
compiling/linking for, it could always prepend the appropriate path, no?
That sounds like a good plan. Unfortunately, libtool does not appear
to check ABIs while linking. Instead it uses the first library that
it finds.
This would of course only fix the -l case. It wouldn't work if *.{l,}a files are
specified directly. But IMHO, whatever is specifying the files directly has to
make sure it takes the right ones itself.
Only way I could think of to fix .la files would be to compare the output of
`file -L lib${name}.so` with they output of file on a little program we just
compile ourself. However, that would break if the .so file is not the library
itself but e.g. a ld script.
A longer term approach would be to encode the ABI into the .la files
so that .la files with the wrong ABI can be quickly skipped without
inspecting the associated library.
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: multilib support
Bob Friesenhahn wrote: Uhm, why is that a problem? If libtool did a check which ABI it's actually compiling/linking for, it could always prepend the appropriate path, no? That sounds like a good plan. Unfortunately, libtool does not appear to check ABIs while linking. Instead it uses the first library that it finds. I know, that's why I reported this bug :P Is there anything that prevents it from checking the current ABI and comparing it with the ABI of the library in question? A longer term approach would be to encode the ABI into the .la files so that .la files with the wrong ABI can be quickly skipped without inspecting the associated library. That of course would be the best way to go. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: multilib support
On Fri, 31 Mar 2006, Simon Stelling wrote: Bob Friesenhahn wrote: Uhm, why is that a problem? If libtool did a check which ABI it's actually compiling/linking for, it could always prepend the appropriate path, no? That sounds like a good plan. Unfortunately, libtool does not appear to check ABIs while linking. Instead it uses the first library that it finds. I know, that's why I reported this bug :P Is there anything that prevents it from checking the current ABI and comparing it with the ABI of the library in question? Anything is possible! The main issue is when such capabilities can be delivered. The release of libtool 2.0 is presumably very soon now so perhaps there is time for adding stop-gap work-arounds in well-known situations (e.g. Solaris maybe Linux), but a later release of libtool would need to properly address multi-arch systems. If the library architecture is encoded in .la files, then a utility could be developed to update existing .la files so they include the architecture. Distributions which discard .la files would be at a disadvantage. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: multilib support
Hi Simon, Bob, Sorry for the delay. * Bob Friesenhahn wrote on Sun, Mar 12, 2006 at 04:53:37PM CET: On Sat, 11 Mar 2006, Simon Stelling wrote: It seems like libtool has some problems on multilib-enabled systems. Yes. When libtool is given a -l argument is tries to find a matching libtool archive by searching through various paths: for searchdir in '$newlib_search_path' '$lib_search_path' '$sys_lib_search_path' '$shlib_search_path' I observe the same problems for Solaris SPARC. The problem is that GCC outputs paths which are not decorated for the specified architecture and libtool blindly uses them. That is only half of the problem. If it were the only problem, then we could just prepend all the lib64 paths on GNU/Linux, and the sparcv9 ones on Solaris. The other half is that libtool does not skip libraries it finds there: deplibs_check_method is set to pass_all. So the task is: find a good replacement for that which is both cheap and accurate. And feasible. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: multilib support
On Sat, 11 Mar 2006, Simon Stelling wrote: It seems like libtool has some problems on multilib-enabled systems. When libtool is given a -l argument is tries to find a matching libtool archive by searching through various paths: for searchdir in '$newlib_search_path' '$lib_search_path' '$sys_lib_search_path' '$shlib_search_path' I observe the same problems for Solaris SPARC. The problem is that GCC outputs paths which are not decorated for the specified architecture and libtool blindly uses them. If libtool included a test for the architecture, then it could decorate the search paths with the subdirectory where the libraries for that architecture lives. On multilib systems, GCC itself automatically decorates the search path so that the correct libraries are used, but libtool circumvents this automatic support. I think that the problem is a result of a GCC bug, but libtool needs to work with what it is given. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
