Re: [RFC] Fix udev pulling in libvolume-id-dev

[Denys Dmytriyenko <denis@denix.org>]

On Wed, Jan 14, 2009 at 11:37:10PM -0800, Khem Raj wrote:
> On (15/01/09 01:14), Denys Dmytriyenko wrote:
> > I was debugging the strange behavior of one of my boxes pulling in libc6-dev 
> > into the filesystem image and it happened to be because udev pulled in 
> > libvolume-id-dev instead of libvolume-id0... It worked as expected on the 
> > other box, though.
> > 
> > Several people on IRC have seen this lingering bug before, but no fix was 
> > available. Koen mentioned it got fixed for him by rebuilding udev...
> > 
> > After some investigation I found out that both libvolume-id packages (-dev and 
> > regular) are registered to provide libvolume_id.so.0 and the one appearing 
> 
> I think -dev provides libvolume_id.so and libvolume-id provides
> libvolume-id.so.* they are different. Our shlib handler should be able
> to figure that out. I still wonder what caused it to pull libc-dev
> though.

The shlib handler from the package.bbclass examines every package by running 
objdump and looking for SONAME/NEEDED sections of all the executables and 
lib*.so files. So, the real .so library from libvolume-id gets identified as 
a provider for libvolume_id.so.0, which is correct. Then libvolume-id-dev 
gets examined, and it does not provide any shlibs. But since it has a symlink, 
which points to a real host .so, objdump picks up its SONAME and -dev gets 
also identified as a provider of libvolume_id.so.0, which is wrong.

Since most of other libraries with -dev split have either relative symlinks 
(../..) or pointing to the same directory, they never get into this issue, 
becuase when -dev is examined, the symlink is broken, as -dev gets installed 
into a separate directory.

That's the reason for my patch to package.bbclass to skip symlinks when 
running objdump.

libc-dev gets pulled in by libvolume-id-dev, for some reason, according to:
libvolume_id_dev -> libc6_dev [style=dotted];

> > last in os.walk() gets pulled in by udev. The order of files provided by 
> > os.walk() depends on parallel builds and phase of the Moon.
> > 
> > libvolume-id-dev does not provide the actual .so library, but it contains a 
> > symlink in /usr/lib, which points to /lib/libvolume.so.0 (the host one!) 
> > instead of ../../lib/ one...
> > 
> > The first patch attached fixes this in udev and should be a no brainer. Unless 
> > someone objects, I'll push it in in a day or two.
> 
> Seems like we need this to work in a sysrooted env. 

With the patch to package.bbclass it can be left as is.

> > Since I was debugging the code which actually does this shlib magic in 
> > package.bbclass, I thought it might be useful to prevent this kind of issues 
> > in the future by skipping symlinks while looking for SONAME/NEEDED in the 
> > objdump - please see the second patch attached and provide feedback.
> 
> But we need to process symlinks to find out package that contains target so that we can create
> dependency on the package that contains target like in this case we need
> to create dependency on libvolume-id for libvolume-id-dev because the
> symlink points to a file provided by libvolume-id

I'm not sure where this dependency gets built, but I believe it is not done by 
the package_do_shlibs() code from package.bbclass I'm referring to. This code 
populates ${STAGING_DIR_HOST}/shlibs, listing .so each pkg provides.

I guess we need more Core devs to look into this issue to verify the safety of 
this patch.

> btw. nice analysis

Thanks.

-- 
Denys