Re: Shared library packaging

[Gary Thomas <gary@mlbassoc.com>]

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

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

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------