[yocto] .rpm packaging weirdness of dynamic libraries

[Hans Beckérus]

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