On Thu, May 23, 2013 at 5:47 PM, Burton, Ross <ross.bur...@intel.com> wrote: > On 23 May 2013 16:25, Hans Beckérus <hans.becke...@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.bur...@intel.com> wrote: > On 23 May 2013 16:25, Hans Beckérus <hans.becke...@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 _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
