* Shared library packaging
@ 2011-03-16 22:10 Gary Thomas
2011-03-16 22:23 ` Mark Hatle
0 siblings, 1 reply; 5+ messages in thread
From: Gary Thomas @ 2011-03-16 22:10 UTC (permalink / raw)
To: Poky
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
Is there a way to [easily?] force these two libraries to be packaged
into nss-XXX.ipk?
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.
Any ideas? Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Shared library packaging
2011-03-16 22:10 Shared library packaging Gary Thomas
@ 2011-03-16 22:23 ` Mark Hatle
2011-03-16 22:27 ` Gary Thomas
0 siblings, 1 reply; 5+ messages in thread
From: Mark Hatle @ 2011-03-16 22:23 UTC (permalink / raw)
To: poky
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Shared library packaging
2011-03-16 22:23 ` Mark Hatle
@ 2011-03-16 22:27 ` Gary Thomas
2011-03-16 22:38 ` Mark Hatle
0 siblings, 1 reply; 5+ messages in thread
From: Gary Thomas @ 2011-03-16 22:27 UTC (permalink / raw)
To: Mark Hatle; +Cc: poky
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Shared library packaging
2011-03-16 22:27 ` Gary Thomas
@ 2011-03-16 22:38 ` Mark Hatle
2011-03-17 7:36 ` Khem Raj
0 siblings, 1 reply; 5+ messages in thread
From: Mark Hatle @ 2011-03-16 22:38 UTC (permalink / raw)
To: Gary Thomas; +Cc: poky
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Shared library packaging
2011-03-16 22:38 ` Mark Hatle
@ 2011-03-17 7:36 ` Khem Raj
0 siblings, 0 replies; 5+ messages in thread
From: Khem Raj @ 2011-03-17 7:36 UTC (permalink / raw)
To: Mark Hatle; +Cc: poky
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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
--
-Khem
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-03-17 7:35 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-16 22:10 Shared library packaging Gary Thomas
2011-03-16 22:23 ` Mark Hatle
2011-03-16 22:27 ` Gary Thomas
2011-03-16 22:38 ` Mark Hatle
2011-03-17 7:36 ` Khem Raj
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.