Re: [PATCH] Add --print-dirs option for ldconfig

[Dan Nicholson <dbn dot lists at gmail dot com>]

On 5/11/12, Roland McGrath <roland@hack.frob.com> wrote:
>> On Mon, Apr 02, 2012 at 11:14:19AM -0700, Roland McGrath wrote:
>> > Exactly what uses is this intended for?
>>
>> Figuring out where the linker is looking for libraries since it's not
>> really documented anywhere.
>
> More exact, please. ;-)
>
> Do you mean the linker (ld) at link time?
>
> Do you mean ldconfig?
>
> Do you mean all the places the dynamic linker might look on
> your installation?  (I think that should be the same answer
> as ldconfig.)
>
> Do you mean the actual places the dynamic linker will in fact look
> if you ran a program right now on the current machine?  (That is
> a subset of the previous answer.)

Precisely :) I thought they were all the same before I started looking
at the code. I definitely mean either ldconfig or the dynamic linker.
I'm pretty sure I mean either the 2nd or 3rd.

>> * The non-existent directories won't be shown. It could be nice to
>>   know all the possible directories, but didn't seem ncessary.
>
> Depends what you want.  If you're trying to decide where is the truly
> proper place to put something new, then it might well be one of the
> directories that doesn't exist now but would be used if it did.
>
>> * The path built up by ldconfig puts the hwcap directories at the end.
>>   I would have expected them to come at the beginning like
>>   LD_DEBUG=libs shows. It does seem that things work out correctly in
>>   the cache, though.
>
> ldconfig is enumerating everything and storing each one in the cache along
> with the bit mask of HWCAP bits that control whether to actually select it.
> The dynamic linker at runtime is using a search path controlled by the
> current HWCAP bits, and stopping when it finds the first hit.
>
> So I still need to understand with much more precision what your actual use
> case is.

There are a few things I would find useful from this information. I'll
try to put them in order of importance.

1. Discoverability. I want the equivalent of "echo $PATH" for shared
libraries. It's simple to figure out what program is going to run
before I enter a command into a shell. Not so much for shared
libraries. It would be nice if I could login to a new system and
immediately get an idea of how the dynamic linker is setup without
trying to infer that information from a bunch of out of band data.

2. A canonical representation of the system library paths. Right now
it's usually /lib:/usr/lib on x86 and /lib64:/lib:/usr/lib64:/usr/lib
on x86_64, I think. I only know that from convention, though. What if
I'm on a Debian system? I'm pretty sure they don't follow the lib64
convention, but the only way you'd know that is to look and
investigate or google. What about when x32 is deployed and I need to
know whether glibc supports it or not? This should be easy to know.

3. Build/install tool perspectives. Where's a reasonable place to
install this library? Is this path part of the dynamic linker search
path? Do I need to add an entry to ld.so.conf? Does this library need
RPATH?

To me the hwcap entries are useful information but not what I'm after
right now. The only reason I started pursuing them is because of #3
where /lib/tls is a "system" path, but you wouldn't know it if you
just got the base directories. Frankly, though, I rarely see these
used in practice.

--
Dan