[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec

From: Gary V. Vaughan
Subject: Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec
Date: Fri, 5 Dec 2014 12:11:57 +0000

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 
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
>> ( 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 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.

Gary V. Vaughan (gary AT gnu DOT org)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]