Hi Pavel,
> On Dec 5, 2014, at 10:07 AM, Pavel Raiskup <prais...@redhat.com> wrote:
>
> On Thursday 04 of December 2014 17:51:28 Gary V. Vaughan wrote:
>> Hi Orion,
>> [...]
>> Does this work for you?
>>
>> diff --git a/m4/libtool.m4 b/m4/libtool.m4
>> [...]
>> + case $host_cpu in
>> + # match at least x86_64, ia64, powerpc64*
>> + *64*) sys_lib_dlsearch_path_spec="/lib64 /usr/lib64
>> $sys_lib_dlsearch_path_spec" ;;
>> + esac
>
> Hi Gary, thanks a lot for the patch!
No problem, it's far from perfect, but at least a step in the right
direction.
> This really needs to be sorted out.
> However this approach does not match the s390x at least.
As in `case $host_cpu in *64*|s390x) ...` ? I can add that if you'd like?
> Until ldconfig
> gives us correct (and fast) list of real directories, could we do some
> better heuristic? I mean something like if the architecture is really
> 64bit (check during configure time perhaps), or check for
> {/usr/lib64,/lib64} existence? Or hardcode that unconditionally (Fedora
> does that from 2009 and AFAIK there have been no complains since then).
Well sure, better heuristics is all we really have :-)
I'm reluctant to add the 64bit directories unconditionally in that part of the
code, because no matter how well it works on Fedora, Libtool has to consider
all the other OSes it supports too; and I don't want to break homebrewed
multi-libbed devenvs put together on big iron machines that don't really have
an established location. That is, I might have /usr network mounted across
several architectures, where /usr/sparcv9 is where my 64bit libs live, and
/usr/lib64 is where I cross compile my x86_64 libraries. Libtool already works
in this kind of environment, and I really don't want to break it unnecessarily.
I'm not sure it's safe to rely on directory existence as an indicator either,
since we can't be sure whether libtool is being used to bootstrap the first
library into a 64-bit system directory that ld.so will check at runtime but
won't
be an actual directory on the file system until this first build is finished.
A configure time check for 64bitness is not unreasonable, and I'd accept a patch
to do that... however, the precedent is to key everything off giant $host_os
(et.al) case statements for speed, as I did with this patch. Also, I can be
sure that tackling this one small piece at a time won't cause regressions in
other parts of the code, and potentially supports weird vendor directories like
pa20_64 on hppa, or sparcv9 on solaris should someone find a need to submit a
self-contained patch to support those.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
