[yocto] .rpm packaging weirdness of dynamic libraries

[Hans Beckérus]

On Thu, May 23, 2013 at 6:01 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> On Thu, May 23, 2013 at 5:47 PM, Burton, Ross <ross.burton at intel.com> wrote:
>> On 23 May 2013 16:25, Hans Beckérus <hans.beckerus at gmail.com> wrote:
>>> Well, yes and no ;) If I look in /lib there are plenty of libraries
>>> that comes with .so files so it seems they are needed in some cases,
>>> right? Also, since part of our system software is doing loading of
>>> dynamic libraries themselves using dlopen() it is *very* hard to
>>> enforce removal of .so files since that piece of software does not
>>> know what particular version of the library it should use. It should
>>> load whatever .so points to, most commonly the latest version. So, is
>>> there some way for us to make sure .so files are also part of the
>>> .rpm? we do not wish to install the -dev variant since it also
>>> pollutes the system with a lot of other not needed stuff. Since /lib
>>> is having a lot of of .so files it must be possible, or?
>>> Actually, I have never seen a system that does not include also the
>>> .so files? Not even embedded ones. They are only soft links so
>>> flash/ram/disk space is not really an issue here.
>>
>> *Every* mainstream linux distribution will not ship .so symlinks
>> unless you've installed the development files, or they are needed for
>> some reason (generally, the .so won't be a symlink in that case).  If
>> a particular library is designed to be unversioned and dlopen'd using
>> a .so filename, then change the FILES as appropriate.  If your package
>> is dlopening arbitrary versioned libraries though libfoo.so filenames
>> then you can either do more work and find the real name, or mess
>> around with the packaging yourself.
>>
>> Ross
>
> Sure. I am not questioning mainstream decision not to ship the .so
> symlinks. I most likely have never encountered real mainstream
> embedded systems before ;) Only home-brewed (we-can-do-it-ourselves)
> things. What I needed was some sort of pointer on how to handle the
> case when you do need to violate the mainstream rules :(
> I will play around with the FILES setting to see if it will get us
> were we need to be. I really do not wish to tamper with the packaging
> routines. It does what it does, with an obviously good reason too :P
>
> Thanks!
> Hans
>
>
Hmm. I tried the FILES trick, but either I am doing something wrong or
FILES does not really affect whats getting into the .rpm? This is what
I tried in our recipe

FILES_${PN} += " ${exec_prefix}/usr/lib/libelinx.so"
FILES_${PN} += " ${exec_prefix}/usr/lib/libepmq.so"

But I see now that dev RPM in addition to the normal RPM is what we
need besides the .la files but I think we we can live with that  ;) Is
there some simple/clever trick to have both the standard and the dev
RPM being installed on the rootfs?

Hans


On Thu, May 23, 2013 at 6:01 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> On Thu, May 23, 2013 at 5:47 PM, Burton, Ross <ross.burton at intel.com> wrote:
>> On 23 May 2013 16:25, Hans Beckérus <hans.beckerus at gmail.com> wrote:
>>> Well, yes and no ;) If I look in /lib there are plenty of libraries
>>> that comes with .so files so it seems they are needed in some cases,
>>> right? Also, since part of our system software is doing loading of
>>> dynamic libraries themselves using dlopen() it is *very* hard to
>>> enforce removal of .so files since that piece of software does not
>>> know what particular version of the library it should use. It should
>>> load whatever .so points to, most commonly the latest version. So, is
>>> there some way for us to make sure .so files are also part of the
>>> .rpm? we do not wish to install the -dev variant since it also
>>> pollutes the system with a lot of other not needed stuff. Since /lib
>>> is having a lot of of .so files it must be possible, or?
>>> Actually, I have never seen a system that does not include also the
>>> .so files? Not even embedded ones. They are only soft links so
>>> flash/ram/disk space is not really an issue here.
>>
>> *Every* mainstream linux distribution will not ship .so symlinks
>> unless you've installed the development files, or they are needed for
>> some reason (generally, the .so won't be a symlink in that case).  If
>> a particular library is designed to be unversioned and dlopen'd using
>> a .so filename, then change the FILES as appropriate.  If your package
>> is dlopening arbitrary versioned libraries though libfoo.so filenames
>> then you can either do more work and find the real name, or mess
>> around with the packaging yourself.
>>
>> Ross
>
> Sure. I am not questioning mainstream decision not to ship the .so
> symlinks. I most likely have never encountered real mainstream
> embedded systems before ;) Only home-brewed (we-can-do-it-ourselves)
> things. What I needed was some sort of pointer on how to handle the
> case when you do need to violate the mainstream rules :(
> I will play around with the FILES setting to see if it will get us
> were we need to be. I really do not wish to tamper with the packaging
> routines. It does what it does, with an obviously good reason too :P
>
> Thanks!
> Hans
>
>
> On Thu, May 23, 2013 at 5:47 PM, Burton, Ross <ross.burton at intel.com> wrote:
>> On 23 May 2013 16:25, Hans Beckérus <hans.beckerus at gmail.com> wrote:
>>> Well, yes and no ;) If I look in /lib there are plenty of libraries
>>> that comes with .so files so it seems they are needed in some cases,
>>> right? Also, since part of our system software is doing loading of
>>> dynamic libraries themselves using dlopen() it is *very* hard to
>>> enforce removal of .so files since that piece of software does not
>>> know what particular version of the library it should use. It should
>>> load whatever .so points to, most commonly the latest version. So, is
>>> there some way for us to make sure .so files are also part of the
>>> .rpm? we do not wish to install the -dev variant since it also
>>> pollutes the system with a lot of other not needed stuff. Since /lib
>>> is having a lot of of .so files it must be possible, or?
>>> Actually, I have never seen a system that does not include also the
>>> .so files? Not even embedded ones. They are only soft links so
>>> flash/ram/disk space is not really an issue here.
>>
>> *Every* mainstream linux distribution will not ship .so symlinks
>> unless you've installed the development files, or they are needed for
>> some reason (generally, the .so won't be a symlink in that case).  If
>> a particular library is designed to be unversioned and dlopen'd using
>> a .so filename, then change the FILES as appropriate.  If your package
>> is dlopening arbitrary versioned libraries though libfoo.so filenames
>> then you can either do more work and find the real name, or mess
>> around with the packaging yourself.
>>
>> Ross