LEAD_SONAME?

LEAD_SONAME?

[Tom Cooksey]

I get a warning saying:

NOTE: Multiple libraries (...) found and LEAD_SONAME not defined

The only documentation I can find is on:

http://www.openembedded.org/user-manual&dpage=recipes_misc

in a section described as: "This section is to be completed."


The other recipies which use it don't have any comments indicating
what it does or how it should be used? I also can't find anything in 
the archives. I'm guessing it's got something to do with automatic 
dependency tracking? Do I just list the shared libraries my package 
provides? If so, which version? The .so, .so.major, .so.major.minor or 
the complete .so.major.minor.patch?


Cheers,

Tom

Re: LEAD_SONAME?

[Tom Cooksey]

On Thursday 27 March 2008 12:17:41 Tom Cooksey wrote:
> I'm guessing it's got something to do with automatic 
> dependency tracking? Do I just list the shared libraries my package 
> provides? If so, which version? The .so, .so.major, .so.major.minor or 
> the complete .so.major.minor.patch?

Ok, I've tried adding all the libraries the package contains to LEAD_SONAME,
but now it's complaining with this:

NOTE: Multiple matches (...) for LEAD_SONAME 'libQt*'

So I guess it's only designed for a single .so file? What about packages with
multiple .so files?

I see this is all going on in debian.bbclass. Does this mean .ipkgs are now
debs?

I am actually splitting off all the individual libraries into seperate packages,
so should I be defining LEAD_SONAME_foo?

I'm also getting a truely bizzare problem, possibly related, where .so files are
missing from the packages. If I look in ${WORKDIR}/install I get a directory
for each package I've defined. The packages which should have .so files in
${libdir} are missing these files. However, I also have some .so files (plugins)
in a different directory, and they are fine?

I'm very confused, please could someone shed some light for me?


Cheers,

Tom

Re: LEAD_SONAME?

[Holger Freyther]

On Thursday 27 March 2008 12:17:41 Tom Cooksey wrote:
> I get a warning saying:
>
> NOTE: Multiple libraries (...) found and LEAD_SONAME not defined

Hi Tom,

this has to do with debian package renaming. This happens when someone (e.g. 
your distro as part of its policies) INHERITS the debian bbclass.

What is happening:
	Imagine I have a package foo and only install a libfoo.so.1.0.0 in the 
libdir. AFAIK according to debian packaging policies the package gets renamed 
from foo to libfoo1. If you have more than one lib installed OE does not know 
which lib name to pick and will print the warning (debian.bbclass:83).

Your options are:
	- Ignore the warning
	- Define a LEAD_SONAME of your primary lib
	- More finegrained packaging.


helpful?
	z.

Re: LEAD_SONAME?

[Tom Cooksey]

On Thursday 27 March 2008 15:44:02 Holger Freyther wrote:
> On Thursday 27 March 2008 12:17:41 Tom Cooksey wrote:
> > I get a warning saying:
> >
> > NOTE: Multiple libraries (...) found and LEAD_SONAME not defined
> 
> this has to do with debian package renaming. This happens when someone (e.g. 
> your distro as part of its policies) INHERITS the debian bbclass.
> 
> What is happening:
> 	Imagine I have a package foo and only install a libfoo.so.1.0.0 in the 
> libdir. AFAIK according to debian packaging policies the package gets renamed 
> from foo to libfoo1. If you have more than one lib installed OE does not know 
> which lib name to pick and will print the warning (debian.bbclass:83).

Ok, well I'm not sure I like the idea of packages being renamed outside my control,
I wouldn't know which name to use in DEPENDS in other recipies. There is also the
issue of image recipies not knowing about the new name, so I can't just add my
package to the list in the image recipie.

> Your options are:
> 	- Ignore the warning
My prefered option, but only if this is not causing my dissappearing library issue.

> 	- Define a LEAD_SONAME of your primary lib
> 	- More finegrained packaging.
Do you mean doing having LEAD_SONAME_foo, LEAD_SONAME_bar, etc. ? That
could work?

> helpful?
Always. :-)

Re: LEAD_SONAME?

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Cooksey schreef:
| On Thursday 27 March 2008 15:44:02 Holger Freyther wrote:
|> On Thursday 27 March 2008 12:17:41 Tom Cooksey wrote:
|>> I get a warning saying:
|>>
|>> NOTE: Multiple libraries (...) found and LEAD_SONAME not defined
|> this has to do with debian package renaming. This happens when
someone (e.g.
|> your distro as part of its policies) INHERITS the debian bbclass.
|>
|> What is happening:
|> 	Imagine I have a package foo and only install a libfoo.so.1.0.0 in the
|> libdir. AFAIK according to debian packaging policies the package gets
renamed
|> from foo to libfoo1. If you have more than one lib installed OE does
not know
|> which lib name to pick and will print the warning (debian.bbclass:83).
|
| Ok, well I'm not sure I like the idea of packages being renamed
outside my control,
| I wouldn't know which name to use in DEPENDS in other recipies.

OE takes care of that automagically.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH69TXMkyGM64RGpERAky5AKCc5MQXVV0RxJNA4e5hlG3AaNjONgCfaSOo
vaKGmC/9xBygCzMToyC8DPY=
=Mnqv
-----END PGP SIGNATURE-----

Re: LEAD_SONAME?

[Richard Purdie]

On Thu, 2008-03-27 at 17:52 +0100, Tom Cooksey wrote:
> Ok, well I'm not sure I like the idea of packages being renamed outside my control,
> I wouldn't know which name to use in DEPENDS in other recipies. There is also the
> issue of image recipies not knowing about the new name, so I can't just add my
> package to the list in the image recipie.

There used to be this problem but it doesn't exist these days. In
DEPENDS you use the recipe PN. In R* varaibles like RDEPENDS you use the
name as it is in PACKAGES. Any renaming will automatically be taken into
account.

debian.bbclass is the typical example of this and probably where your
LEAD_SONAME warning is coming from.

> > Your options are:
> > 	- Ignore the warning
> My prefered option, but only if this is not causing my dissappearing library issue.
> 
> > 	- Define a LEAD_SONAME of your primary lib
> > 	- More finegrained packaging.
> Do you mean doing having LEAD_SONAME_foo, LEAD_SONAME_bar, etc. ? That
> could work?

No, select one e.g. if libfoo is the most "important", LEAD_SONAME =
"libfoo".

Cheers,

Richard

Re: LEAD_SONAME?

[Holger Freyther]

On Thursday 27 March 2008 17:52:07 Tom Cooksey wrote:

> Ok, well I'm not sure I like the idea of packages being renamed outside my
> control, I wouldn't know which name to use in DEPENDS in other recipies.
> There is also the issue of image recipies not knowing about the new name,
> so I can't just add my package to the list in the image recipie.

Hehe. For DEPENDS this is not an issue, for RDEPENDS it is not an issue as 
well and this is the reason why I ask you to create a task in between, 
because the renaming is failing/not done on image creation. ;)



>
> > Your options are:
> > 	- Ignore the warning
>
> My prefered option, but only if this is not causing my dissappearing
> library issue.

Unlikely


>
> > 	- Define a LEAD_SONAME of your primary lib
> > 	- More finegrained packaging.
>
> Do you mean doing having LEAD_SONAME_foo, LEAD_SONAME_bar, etc. ? That
> could work?

I assume this is with Qt? So you still have separate packages for qtcore, 
qtxml, ...? Why do you have more than one library in these packages anyway? 
But yes LEAD_SONAME_qtcore, LEAD_SONAME_qtxml would clarify things. But again 
findout why there is more than one lib in the package.


z.

Re: LEAD_SONAME?

[Tom Rini]

On Thu, Mar 27, 2008 at 05:13:51PM +0000, Richard Purdie wrote:
> On Thu, 2008-03-27 at 17:52 +0100, Tom Cooksey wrote:
[snip]
> > > Your options are:
> > > 	- Ignore the warning
> > My prefered option, but only if this is not causing my dissappearing library issue.
> > 
> > > 	- Define a LEAD_SONAME of your primary lib
> > > 	- More finegrained packaging.
> > Do you mean doing having LEAD_SONAME_foo, LEAD_SONAME_bar, etc. ? That
> > could work?
> 
> No, select one e.g. if libfoo is the most "important", LEAD_SONAME =
> "libfoo".

Ah, but what's up with wildcards in the field (ie glib-2.0) ?  Or ones
that say "libfoo.so" (postgresql) or "libfoo.so.1" (uim) ?  People guessing
incorrectly at the value?  Thanks!

-- 
Tom Rini

Re: LEAD_SONAME?

[Richard Purdie]

On Thu, 2008-03-27 at 10:45 -0700, Tom Rini wrote:
> On Thu, Mar 27, 2008 at 05:13:51PM +0000, Richard Purdie wrote:
> > On Thu, 2008-03-27 at 17:52 +0100, Tom Cooksey wrote:
> [snip]
> > > > Your options are:
> > > > 	- Ignore the warning
> > > My prefered option, but only if this is not causing my dissappearing library issue.
> > > 
> > > > 	- Define a LEAD_SONAME of your primary lib
> > > > 	- More finegrained packaging.
> > > Do you mean doing having LEAD_SONAME_foo, LEAD_SONAME_bar, etc. ? That
> > > could work?
> > 
> > No, select one e.g. if libfoo is the most "important", LEAD_SONAME =
> > "libfoo".
> 
> Ah, but what's up with wildcards in the field (ie glib-2.0) ?  Or ones
> that say "libfoo.so" (postgresql) or "libfoo.so.1" (uim) ?  People guessing
> incorrectly at the value?  Thanks!

If in doubt, use the source (debian.bbclass):

lead = bb.data.getVar('LEAD_SONAME', d, 1)
if lead:
	r = re.compile(lead)
	filtered = []
	for s in sonames:
	if r.match(s):
		filtered.append(s)

so its being used as a regexp against the sonames. A valid contents of
the field is something which provides a unique match.

Cheers,

Richard