Hi Pavel,
> On Dec 5, 2014, at 11:58 AM, Pavel Raiskup <prais...@redhat.com> wrote:
>
> On Friday 05 of December 2014 10:56:28 Gary V. Vaughan wrote:
>>> 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?
>
> That would be at least better :), but I would still need to check what are
> our all 64bit (WIP-)supported arches.
Since this is the current path of least resistance, please do go ahead and
send me that list (or patch) reasonably soon. I broke OpenBSD with a
mis-applied
patch for 2.4.4, so I'm planning a fast 2.4.5 sometime soon after the weekend,
and it would be nice to have this fix in there too :)
>>> 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 :-)
>>
> [[snip snip]]
>> 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.
>
> Sure, the requirements seem to be clear, thanks! Something like that is
> IMO important for linux distributions because having the list of arches
> hardwired in libtool would result into the same troubles we have now: We
> need to touch all the 'libtool' scripts we have in distribution with new
> architecture.
>
> Yes, we can use ac_cv_.... workaround globally, but that is not
> ideal as this turns off the ld.so.conf parsing in libtool (which works
> pretty well to reimplement).
>
> ... so yet another idea. What about have some API environment variable
> _enhancing_ the library path detected by libtool?
Great idea! Yes, that is a good middle ground without any safety concerns on
my part; I'd be very happy to apply a patch along those lines.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
