[oe] [RFC] Fix udev pulling in libvolume-id-dev
Denys Dmytriyenko
denis at denix.org
Thu Jan 15 15:51:59 UTC 2009
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
More information about the Openembedded-devel
mailing list