[poky] Shared library packaging

[Mark Hatle]

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!)

> 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...)

--Mark

> Any ideas?  Thanks
>