Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec

[Gary V. Vaughan]

Hi Pavel,

> On Dec 5, 2014, at 11:58 AM, Pavel Raiskup <address@hidden> 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)