From: Steffen Sledz <sledz@dresearch-fe.de>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: complex versioning scenario
Date: Tue, 08 Apr 2014 14:33:29 +0200 [thread overview]
Message-ID: <5343EC99.800@dresearch-fe.de> (raw)
In-Reply-To: <1396882151.24597.72.camel@ted>
On 07.04.2014 16:49, Richard Purdie wrote:
> On Mon, 2014-04-07 at 15:22 +0200, Steffen Sledz wrote:
>> On 07.04.2014 14:37, Steffen Sledz wrote:
>>> On 25.03.2014 16:03, Mark Hatle wrote:
>>>> ...
>>>> If the package 'requiring libfoo' has a DEPENDS += ... in it.. then yes, it should have been rebuilt when the libfoo was rebuilt.
>>>
>>> Unfortunately i can't confirm that. :(
>>>
>>> part of the real app recipe:
>>> ------------> snip <-------------
>>> DEPENDS = "vala-native libdrtrace libdrhip libdrbcc jansson"
>>> RDEPENDS_${PN} = "dropmodes"
>>> ------------> snap <-------------
>>>
>>> part of the real resulting opkg control file for this app:
>>> ------------> snip <-------------
>>> Depends: dropmodes, libglib-2.0-0 (>= 2.36.4), libdrhip1 (>= gitr27+42af787eb2), libjansson4 (>= 2.4), libc6 (>= 2.18)
>>> ------------> snap <-------------
>>>
>>> I miss the runtime dependencies for libdrtrace and libdrbcc. Where are they gone?
>>
>> Some additional info:
>> ------------> snip <-------------
>> # objdump -p ./package/usr/lib/libdrhip.so.1.0.0
>>
>> ./package/usr/lib/libdrhip.so.1.0.0: file format elf32-littlearm
>> ...
>> Dynamic Section:
>> NEEDED libc.so.6
>> SONAME libdrhip.so.1
>> ...
>>
>> # objdump -p ./package/usr/lib/libdrbcc.so.1.0.0
>>
>> ./package/usr/lib/libdrbcc.so.1.0.0: file format elf32-littlearm
>> ...
>> Dynamic Section:
>> NEEDED libdrtrace.so.0
>> NEEDED libm.so.6
>> NEEDED libreadline.so.6
>> NEEDED libpthread.so.0
>> NEEDED libc.so.6
>> SONAME libdrbcc.so.1
>> ...
>>
>> # objdump -p ./package/usr/bin/drbccproxy
>>
>> ./package/usr/bin/drbccproxy: file format elf32-littlearm
>> ...
>> Dynamic Section:
>> NEEDED libdrhip.so.1
>> NEEDED libdrbcc.so.0
>> NEEDED libdrtrace.so.0
>> NEEDED libgio-2.0.so.0
>> NEEDED libgobject-2.0.so.0
>> NEEDED libglib-2.0.so.0
>> NEEDED libjansson.so.4
>> NEEDED librt.so.1
>> NEEDED libpthread.so.0
>> NEEDED libc.so.6
>> ...
>> ------------> snap <-------------
>>
>> So it seems the data objdump shows are OK.
>>
>> E.g. the app drbccproxy really has a dependency to a libdrbcc. But this is not refelected in the control file.
>
> At this point you'll probably have to look at the shlibs code in
> package.bbclass and see why its not picking up the shlib dependencies
> correctly for the packages...
>
> It does appear there is some problem there but its hard to saw what
> without a test case to reproduce.
I could isolate the problem. :)
If a package contains a shared library *and* a binary (e.g. a related command line tool) then the soname major version *is not appended* to the package name (see debian_package_name_hook in debian.bbclass). All other problems are aftereffects.
Is this an intended behaviour? There should be a big fat warning if this is the case.
Or is it a bug?
--
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
next prev parent reply other threads:[~2014-04-08 12:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-24 12:16 complex versioning scenario Steffen Sledz
2014-03-24 12:35 ` Richard Purdie
2014-03-24 12:49 ` Steffen Sledz
2014-03-24 12:53 ` Richard Purdie
2014-03-24 14:22 ` Steffen Sledz
2014-03-24 15:07 ` Richard Purdie
2014-03-24 15:15 ` Martin Jansa
2014-03-25 10:31 ` Steffen Sledz
2014-03-25 10:40 ` Richard Purdie
2014-03-25 15:03 ` Mark Hatle
2014-04-07 12:37 ` Steffen Sledz
2014-04-07 13:22 ` Steffen Sledz
2014-04-07 14:49 ` Richard Purdie
2014-04-08 12:33 ` Steffen Sledz [this message]
2014-04-08 17:20 ` Khem Raj
2014-04-08 18:58 ` Steffen Sledz
2014-04-08 21:32 ` Khem Raj
2014-03-24 18:00 ` Khem Raj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5343EC99.800@dresearch-fe.de \
--to=sledz@dresearch-fe.de \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.