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

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

[Howard D. Gray]

Hi,

IMHO it would be useful if packages could install their own *.conf files
in  /etc/ld.so.conf.d/ so that non-standard directories could also be
used for libraries. Many other distributions allow this by using an
"include" line in /etc/ld.so.conf.

Is there any reason for not doing it like this, for example, and then
letting other packages add *.conf files to the directory as they require ?

---
diff --git a/recipes/glibc/glibc-2.10.1/etc/ld.so.conf
b/recipes/glibc/glibc-2.10.1/etc/ld.so.conf
index 46e06d3..c2ae026 100644
--- a/recipes/glibc/glibc-2.10.1/etc/ld.so.conf
+++ b/recipes/glibc/glibc-2.10.1/etc/ld.so.conf
@@ -1,2 +1,3 @@
 /usr/local/lib
+include /etc/ld.so.conf.d/*.conf






-- 
Howard


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

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

[Mark Hatle]

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/ so that non-standard directories could also be
> used for libraries. Many other distributions allow this by using an
> "include" line in /etc/ld.so.conf.
> 
> Is there any reason for not doing it like this, for example, and then
> letting other packages add *.conf files to the directory as they require ?
> 
> ---
> diff --git a/recipes/glibc/glibc-2.10.1/etc/ld.so.conf
> b/recipes/glibc/glibc-2.10.1/etc/ld.so.conf
> index 46e06d3..c2ae026 100644
> --- a/recipes/glibc/glibc-2.10.1/etc/ld.so.conf
> +++ b/recipes/glibc/glibc-2.10.1/etc/ld.so.conf
> @@ -1,2 +1,3 @@
>  /usr/local/lib
> +include /etc/ld.so.conf.d/*.conf

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

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.

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.

--Mark

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

[Howard D. Gray]

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

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

[Mark Hatle]

On 7/14/11 8:23 AM, Howard D. Gray wrote:
> 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".

I agree completely.  I'm willing to ack the addition of the dynamic conf files
to the ld.so.conf file setting.  It would definitely help people working on
their own projects to resolve the issues.

I just don't want to advocate people using this in items checked into oe-core or
meta-oe.  I really feel that the system needs to work (as those layers present
it) without having to run ldconfig.  (Note, any other layers, distributions or
end users are free to use ldconfig if it makes their lives easier.)

--Mark

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