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

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

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@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@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]