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