Re: Adding line to ld.so.conf

[Mark Hatle <mark.hatle@windriver.com>]

On 11/21/11 10:17 AM, Marc Ferland wrote:
> On Mon, Nov 21, 2011 at 11:04 AM, Khem Raj <raj.khem@gmail.com
> <mailto:raj.khem@gmail.com>> wrote:
>
>     On Mon, Nov 21, 2011 at 7:35 AM, Marc Ferland <marc.ferland@gmail.com
>     <mailto:marc.ferland@gmail.com>> wrote:
>      > Hi,
>      >
>      > What's the proper way to add a line to the ld.so.conf file for a new library
>      > I am adding?
>      >
>
>     if the libraries is in standard paths you dont have to add it but if
>     its in a special path
>     then just add the absolute path to the library e.g. /opt/lib if your
>     library is in /opt/lib
>     and then run ldconfig
>
>
> What I meant was how to do it in a recipe file. I don't want to modify
> ld.so.conf and run ldconfig each time I create a new image.

There are issues with playing with ld.so.conf when doing a cross image 
generation.  ldconfig doesn't always work during the rootfs process, most people 
don't notice since it's simply not necessary to be run in most cases!

Lets assume for a minute that it does work in all cases.. (I'll explain a better 
solution in a bit.)

You would want a post install script that:

checks to see if the ld.so.conf already contains the line you need, if it does 
NOT, you would then add the line to the ld.so.conf file.  Then you would run 
ldconfig within the post install script -- if you are not doing a cross install. 
  (Cross installs automatically attempt to run ldconfig.)

Something like...

grep -q /opt/lib ${D}/etc/ld.so.conf || echo /opt/lib >> /etc/ld.so.conf

if [ -z "${D}" ]; then
  ldconfig
fi


The above may work in your local projects, but will likely be rejected from 
submissions to the upstream project as being too fragile.

.....

But there is a better way to do this and avoid using ldconfig.  ldconfig was 
designed to be an optimization, but instead it's turned into a hack to cover up 
mistakes.  It's primary use seems to be to cover up when people forget to create 
symlinks and/or don't specify an SONAME within a library.  The secondary use is 
to add library information for libraries residing in non-standard locations... 
and the tertiary use is to simplify the lookup of the packages to avoid 
iterating over a filesystem.

Instead of using ldconfig, inform the application on the locations of the 
non-standard items.  This will then add them to the search path and ldconfig 
will no longer be necessary for a functional system, and instead become the 
optimization it was originally designed to be.

One way to do this, when you are repackaging something you didn't create and 
only have the binaries for, is to create a wrapper script that sets 
"LD_LIBRARY_PATH=<path to library>" and then executes the action binary..

or

If you are doing the compilation, use a built-in RPATH to specify where your 
application libraries exist.  See: http://itee.uq.edu.au/~daniel/using_origin/ 
for a good explanation of what to pass to the linker and how to use "$ORIGIN" to 
make it easier -- and your application relocatable on the target.  But in short 
you hard-code at compile time the location of your libraries based on the 
location of your executables.

--Mark

> Regards,
>
> Marc
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto