[poky] Shared library packaging

[Khem Raj]

On (16/03/11 17:38), Mark Hatle wrote:
> On 3/16/11 5:27 PM, Gary Thomas wrote:
> > On 03/16/2011 04:23 PM, Mark Hatle wrote:
> >> On 3/16/11 5:10 PM, Gary Thomas wrote:
> >>> I'm working on a recipe which has a number of shared libraries (actually
> >>> this is just an import from OE (mozilla/nss) which has the same problem as listed below)
> >>> The package creates a number of libraries (from the work tree):
> >>>       image/usr/lib/libsmime3.so ->  libsmime3.so.1oe
> >>>       image/usr/lib/libsmime3.so.1oe
> >>>       image/usr/lib/libsoftokn3.so
> >>>       image/usr/lib/libfreebl3.so
> >>>       image/usr/lib/libnssutil3.so ->  libnssutil3.so.1oe
> >>>       image/usr/lib/libnssutil3.so.1oe
> >>>       image/usr/lib/libnss3.so ->  libnss3.so.1oe
> >>>       image/usr/lib/libnss3.so.1oe
> >>>       image/usr/lib/libssl3.so ->  libssl3.so.1oe
> >>>       image/usr/lib/libssl3.so.1oe
> >>>
> >>> The .so.1oe files are packaged in nss_XXX.ipk and the .so files are
> >>> put into nss-dev_XXX.ipk.  The problem is that there is code out there
> >>> that only wants to look for the .so files (no -dev packages installed)
> >>> and fail to find libsoftokn3.so and libfreebl3.so
> >>
> >> This sounds like an error in the SONAME embedded in the files.  For example if
> >> the soname of libnss2.so.1oe, is libnss3.so, both it and the link will be
> >> captured in the base package -- leaving the -dev empty.
> >>
> >> (If the SONAME is correct and it's not working this way that is likely a bug in
> >> the routines breaking up base and dev packages!)
> > 
> > How can I check this (not my comfort zone)?
> 
> I usually run "readelf -a <library>"  and then grep for SONAME.
> 
> It's likely better to run the target version of readelf if the target is not IA32.
> 
> >>
> >>> Is there a way to [easily?] force these two libraries to be packaged
> >>> into nss-XXX.ipk?
> >>
> >> Assuming fixing the sonames is not an option, the alternative is to specify the
> >> packages and FILES_... list of files for each chunk instead of letting the
> >> system determine things automatically.  It's a bit messier, but you have
> >> ultimate control of what is and is not included...
> >>
> >>> My current workaround is to use a post-install script to create the .so
> >>> files from the .so.1oe files for these two libraries.  It gets my code
> >>> (chromium-11 browser!) to work, but it's not very satisfying.
> >>
> >> If possible, fix the soname item... otherwise there can be loader problems if
> >> the device doesn't end up with an ld.so.cache...  (which is why the link is
> >> working I suspect...)
> > 
> > I think the problem is in some very messy Mozilla code that uses dl_load() directly
> > and only looks for the .so file name.
> > 
> > I'll probably go with the FILES solution.
> > 
> 
> Ya, dl_loaded files don't follow the normal conventions, the files approach is
> likely your only solution then.

if you enable QA/insane.bbclass then you will get QA errors  for ".so"
library symlinks in non-dev packages

So you might have to disable QA for this case.

> 
> --Mark
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

-- 
-Khem