[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: Pavel Raiskup
Subject: Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec
Date: Fri, 05 Dec 2014 12:58:29 +0100
User-agent: KMail/4.14.3 (Linux/3.17.3-200.fc20.x86_64; KDE/4.14.3; x86_64; ; )

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.

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

Agreed.  Such changes are tricky.  But we installed such patch in Fedora
and it has been out in the wild for some time;  upstreams using
Fedora/RHEL are now producing tarballs with patched libtool this way.

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

If the Fedora-origin upstream tarballs could be considered good statistic
measurement, I think such advanced concerned users are prepared already
(and probably also are reading this list).  But thats tough I have to

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

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?


reply via email to

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