[yocto] .rpm packaging weirdness of dynamic libraries

[Hans Beckérus]

On Thu, May 23, 2013 at 7:16 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> 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?
>

Oops! Already spotted my typo there. It should of course be

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

But unfortunately I did not make any difference to the .rpm file :(

Hans

On Thu, May 23, 2013 at 7:16 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> 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