Re: angstrom: glibc: Using config files in /etc/ld.so.conf.d/

["Howard D. Gray" <howard.gray@matrix-vision.de>]

Mark,

On 14/07/11 03:27, Mark Hatle wrote:
> On 7/13/11 12:22 PM, Howard D. Gray wrote:
>> Hi,
>>
>> IMHO it would be useful if packages could install their own *.conf files
>> in  /etc/ld.so.conf.d/ ...

> 
> I agree this is a good idea, however...
> 
> If the apps you are creating require ld.so.conf, and thus ldconfig in order to
> execute..  then most likely the app in question has a bug..  (I say most likely,
> because that is not always true.)
> 
> For the systems I work with, my rule of thumb is that everything that goes into
> a system directory should never need ldconfig to run...  If it does, it means
> there is a broken soname somewhere in the system.
> 
> For items that are outside of the standard set of directories, they should have
> rpaths embedded (based on the target filesystem) that tell the components how
> and where to find their non-standard located components.

> (chrpath can do this in many cases..)

OK. For our applications I think we should be able to use rpath when
building as you suggest or possibly tweak the rpath tag with chrpath
during installation. I have only very limited control over the build
process for the libraries used by this app - in particular the directory
hierarchy - which is why I preferred to install them somewhere
non-standard.

> Sometimes when using third party binaries that is not possible of course..
> However, creating a simple shell wrapper that adds the necessary paths to
> LD_LIBRARY_PATH is a good solution.

This is a solution we have used before but it caused confusion for
normal Linux users with a PC. However, on an embedded board it could be
the simplest option.

> But, if all else fails, ld.so.conf should work.
> 
> IMHO all of the alternatives are better approaches because they ensure the apps
> and system components work as intended, and don't rely on the crutch of the
> dynamic loader cache to be able to find the intended items.  Speed wise, if the
> items are in the standard directories there is no performance penalty (thats
> I've been able to determine) to -not- have an ld.so.cache on the system.. for
> items outside of the standard directories, the penalty is so minor -- and only
> occurs on app startup that it still doesn't make sense to me to have an
> ld.so.cache...  (it simply takes a lot of disk space, and requires an ldconfig
> operation to occur.)
> 
> Long story short, I don't mind the suggestion.. but I will look for alternatives
> to someone putting in a .conf file over allowing the .conf file any day.

Just adding the "include" line to ld.so.conf only opens up the
possibility for other apps to maintain their own *.conf files without
having to worry about other paths in ld.so.conf. It doesn't mean that
*.conf files *have* to be used or that ld.so.cache will be required on a
system without such *.conf files. Of course, it might be considered to
be encouraging "bad practices".

In our case I should be able to use one of the other ways you suggest
and I'll try to do it like that first.

Thanks a lot for taking the time to explain.

-- 
Howard


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier