[OE-core] [PATCH 3/5] package.bbclass: add SHLIBSSEARCHDIRS to define where to search for shlib providers

[Martin Jansa]

On Sun, Jan 19, 2014 at 05:13:45PM +0000, Richard Purdie wrote:
> On Sat, 2014-01-18 at 15:02 +0100, Martin Jansa wrote:
> > * when package contains some files matching "^.*\.so", but in directory
> >   not default linker search paths (e.g. /opt/package/bundled-lib/libfoo.so)
> >   don't register it as libfoo provider, because it's possible that there
> >   is different package providing libfoo.so in ${libdir} and that would
> >   be better shlib provider for other packages to depend on
> > * recipes providing libs intentionally in some other directory can
> >   define own SHLIBSSEARCHDIRS value
> > 
> > [YOCTO #4628]
> > 
> > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> > ---
> >  meta/classes/package.bbclass | 26 +++++++++++++++++++++++---
> >  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> Doesn't this mean we lose automatic dependencies for libraries not in
> the default system paths after this change?

True, recipes with such libraries would need to append to
SHLIBSSEARCHDIRS

> We should really be respecting the libraries RPATH in this code and
> searching the places it will look...

I agree we should respect RPATH, but sometimes it is more complicated,
because your own binaries can have RPATH pointing to
/opt/package/bundled-lib/libfoo.so, but you don't want any other recipe
to find your libfoo.so, because there is preferred "system" /usr/lib/libfoo.so

So in ideal case we should respect combination of default search path,
ld.so.conf, RPATH and PRIVATE_LIBS :/.

I don't mind if you drop this one from patchset, it's the most controversial
one and can be work-arounded by carefully maintained PRIVATE_LIBS list.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140119/41fbe681/attachment-0002.sig>