[poky] Shared library packaging

[Mark Hatle]

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.

--Mark