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

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

[Denys Dmytriyenko]

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

Hi,

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 
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.

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.

-- 
Denys

[-- Attachment #2: udev-124-libvolume-id-soname.patch --]
[-- Type: text/plain, Size: 1690 bytes --]

diff --git a/packages/udev/udev-124/libvolume-id-soname.patch b/packages/udev/udev-124/libvolume-id-soname.patch
new file mode 100644
index 0000000..56365a4
--- /dev/null
+++ b/packages/udev/udev-124/libvolume-id-soname.patch
@@ -0,0 +1,12 @@
+diff -uNr udev-124-orig/extras/volume_id/lib/Makefile udev-124/extras/volume_id/lib/Makefile
+--- udev-124-orig/extras/volume_id/lib/Makefile	2008-06-12 01:24:30.000000000 -0400
++++ udev-124/extras/volume_id/lib/Makefile	2009-01-14 23:32:42.000000000 -0500
+@@ -113,7 +113,7 @@
+ ifeq ($(libdir),$(usrlibdir))
+ 	ln -sf $(SHLIB) $(DESTDIR)$(usrlibdir)/libvolume_id.so
+ else
+-	ln -sf $(libdir)/$(SHLIB) $(DESTDIR)$(usrlibdir)/libvolume_id.so
++	ln -sf ../..$(libdir)/$(SHLIB) $(DESTDIR)$(usrlibdir)/libvolume_id.so
+ endif
+ 	$(INSTALL) -d $(DESTDIR)$(usrlibdir)/pkgconfig
+ 	$(INSTALL_DATA) libvolume_id.pc $(DESTDIR)$(usrlibdir)/pkgconfig/libvolume_id.pc
diff --git a/packages/udev/udev_124.bb b/packages/udev/udev_124.bb
index 515debe..aa156a1 100644
--- a/packages/udev/udev_124.bb
+++ b/packages/udev/udev_124.bb
@@ -3,13 +3,14 @@ DESCRIPTION = "udev is a daemon which dynamically creates and removes device nod
 the hotplug package and requires a kernel not older than 2.6.12."
 RPROVIDES_${PN} = "hotplug"
 
-PR = "r11"
+PR = "r12"
 
 SRC_URI = "http://kernel.org/pub/linux/utils/kernel/hotplug/udev-${PV}.tar.gz \
 	   file://noasmlinkage.patch;patch=1 \
 	   file://flags.patch;patch=1 \
 	   file://vol_id_ld.patch;patch=1 \
 	   file://udevtrigger_add_devname_filtering.patch;patch=1 \
+	   file://libvolume-id-soname.patch;patch=1 \
 	   file://mount.blacklist \
 	   file://run.rules \
 	   "

[-- Attachment #3: package_bbclass-do_shlibs-skip-symlinks.patch --]
[-- Type: text/plain, Size: 606 bytes --]

diff --git a/classes/package.bbclass b/classes/package.bbclass
index 8b7d649..a7cdb5f 100644
--- a/classes/package.bbclass
+++ b/classes/package.bbclass
@@ -615,7 +615,7 @@ python package_do_shlibs() {
 			for file in files:
 				soname = None
 				path = os.path.join(root, file)
-				if os.access(path, os.X_OK) or lib_re.match(file):
+				if (os.access(path, os.X_OK) or lib_re.match(file)) and not os.path.islink(path):
 					cmd = bb.data.getVar('OBJDUMP', d, 1) + " -p " + path + " 2>/dev/null"
 					cmd = "PATH=\"%s\" %s" % (bb.data.getVar('PATH', d, 1), cmd)
 					fd = os.popen(cmd)

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

[Koen Kooi]

On 15-01-09 07:14, Denys Dmytriyenko wrote:

> 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...

That's the intended behaviours, since installing the packages will have 
it point to ${libdir}/libvolume.so.0 on your device. I'm not sure if we 
want to patch every package to use relative symlinks.

> 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.
>
> 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.

The change to package.bbclass looks OK to me, if that gets applied we 
can leave out the udev patch.

regards,

Koen

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

[Khem Raj]

On (15/01/09 01:14), Denys Dmytriyenko wrote:
> Hi,
> 
> 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.

> 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. 

> 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


btw. nice analysis

Thx

-Khem

> 
> -- 
> Denys

> diff --git a/packages/udev/udev-124/libvolume-id-soname.patch b/packages/udev/udev-124/libvolume-id-soname.patch
> new file mode 100644
> index 0000000..56365a4
> --- /dev/null
> +++ b/packages/udev/udev-124/libvolume-id-soname.patch
> @@ -0,0 +1,12 @@
> +diff -uNr udev-124-orig/extras/volume_id/lib/Makefile udev-124/extras/volume_id/lib/Makefile
> +--- udev-124-orig/extras/volume_id/lib/Makefile	2008-06-12 01:24:30.000000000 -0400
> ++++ udev-124/extras/volume_id/lib/Makefile	2009-01-14 23:32:42.000000000 -0500
> +@@ -113,7 +113,7 @@
> + ifeq ($(libdir),$(usrlibdir))
> + 	ln -sf $(SHLIB) $(DESTDIR)$(usrlibdir)/libvolume_id.so
> + else
> +-	ln -sf $(libdir)/$(SHLIB) $(DESTDIR)$(usrlibdir)/libvolume_id.so
> ++	ln -sf ../..$(libdir)/$(SHLIB) $(DESTDIR)$(usrlibdir)/libvolume_id.so
> + endif
> + 	$(INSTALL) -d $(DESTDIR)$(usrlibdir)/pkgconfig
> + 	$(INSTALL_DATA) libvolume_id.pc $(DESTDIR)$(usrlibdir)/pkgconfig/libvolume_id.pc
> diff --git a/packages/udev/udev_124.bb b/packages/udev/udev_124.bb
> index 515debe..aa156a1 100644
> --- a/packages/udev/udev_124.bb
> +++ b/packages/udev/udev_124.bb
> @@ -3,13 +3,14 @@ DESCRIPTION = "udev is a daemon which dynamically creates and removes device nod
>  the hotplug package and requires a kernel not older than 2.6.12."
>  RPROVIDES_${PN} = "hotplug"
>  
> -PR = "r11"
> +PR = "r12"
>  
>  SRC_URI = "http://kernel.org/pub/linux/utils/kernel/hotplug/udev-${PV}.tar.gz \
>  	   file://noasmlinkage.patch;patch=1 \
>  	   file://flags.patch;patch=1 \
>  	   file://vol_id_ld.patch;patch=1 \
>  	   file://udevtrigger_add_devname_filtering.patch;patch=1 \
> +	   file://libvolume-id-soname.patch;patch=1 \
>  	   file://mount.blacklist \
>  	   file://run.rules \
>  	   "

> diff --git a/classes/package.bbclass b/classes/package.bbclass
> index 8b7d649..a7cdb5f 100644
> --- a/classes/package.bbclass
> +++ b/classes/package.bbclass
> @@ -615,7 +615,7 @@ python package_do_shlibs() {
>  			for file in files:
>  				soname = None
>  				path = os.path.join(root, file)
> -				if os.access(path, os.X_OK) or lib_re.match(file):
> +				if (os.access(path, os.X_OK) or lib_re.match(file)) and not os.path.islink(path):
>  					cmd = bb.data.getVar('OBJDUMP', d, 1) + " -p " + path + " 2>/dev/null"
>  					cmd = "PATH=\"%s\" %s" % (bb.data.getVar('PATH', d, 1), cmd)
>  					fd = os.popen(cmd)

> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

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

[Khem Raj]

On (15/01/09 07:56), Koen Kooi wrote:
> On 15-01-09 07:14, Denys Dmytriyenko wrote:
>
>> 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...
>
> That's the intended behaviours, since installing the packages will have  
> it point to ${libdir}/libvolume.so.0 on your device. I'm not sure if we  
> want to patch every package to use relative symlinks.

We would use -dev packages on staged area normally to compile other apps
depending on a given packge if we do not fix the symlink I think it will
try to link to wrong library.


>
>> 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.
>>
>> 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.
>
> The change to package.bbclass looks OK to me, if that gets applied we  
> can leave out the udev patch.
>
> regards,
>
> Koen
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

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

[Koen Kooi]

On 15-01-09 08:41, Khem Raj wrote:
> On (15/01/09 07:56), Koen Kooi wrote:
>> On 15-01-09 07:14, Denys Dmytriyenko wrote:
>>
>>> 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...
>> That's the intended behaviours, since installing the packages will have
>> it point to ${libdir}/libvolume.so.0 on your device. I'm not sure if we
>> want to patch every package to use relative symlinks.
>
> We would use -dev packages on staged area normally to compile other apps
> depending on a given packge if we do not fix the symlink I think it will
> try to link to wrong library.

We don't use the -dev packages to populate staging :) I keep trying to 
convince Richard that we should use them, but he keeps coming up with 
good reasons not to do so :)

regards,

Koen

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

[Denys Dmytriyenko]

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

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

[Denys Dmytriyenko]

On Thu, Jan 15, 2009 at 07:56:37AM +0100, Koen Kooi wrote:
> On 15-01-09 07:14, Denys Dmytriyenko wrote:
>
>> 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...
>
> That's the intended behaviours, since installing the packages will have it 
> point to ${libdir}/libvolume.so.0 on your device. I'm not sure if we want 
> to patch every package to use relative symlinks.

So far, all other packages I looked at, have relative or same-dir symlinks in 
corresponding -dev (libc, libpng, jpeg, gnutls etc)
Since -dev gets run through shlib magic outside of the main package with 
the actual .so, relative or same-dir symlinks are broken, leading to a normal 
behavior :)

>> 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.
>>
>> 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.
>
> The change to package.bbclass looks OK to me, if that gets applied we can 
> leave out the udev patch.

That's the goal :)

-- 
Denys

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

[Khem Raj]

On Thu, Jan 15, 2009 at 3:10 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> On 15-01-09 08:41, Khem Raj wrote:
>>
>> On (15/01/09 07:56), Koen Kooi wrote:
>>>
>>> On 15-01-09 07:14, Denys Dmytriyenko wrote:
>>>
>>>> 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...
>>>
>>> That's the intended behaviours, since installing the packages will have
>>> it point to ${libdir}/libvolume.so.0 on your device. I'm not sure if we
>>> want to patch every package to use relative symlinks.
>>
>> We would use -dev packages on staged area normally to compile other apps
>> depending on a given packge if we do not fix the symlink I think it will
>> try to link to wrong library.
>
> We don't use the -dev packages to populate staging :) I keep trying to
> convince Richard that we should use them, but he keeps coming up with good
> reasons not to do so :)

Hmm then why do we generate them ?. We do not need these packages on
target unless we switch to
native development on target.

>
> regards,
>
> Koen
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Koen Kooi]

On 15-01-09 19:53, Khem Raj wrote:
> On Thu, Jan 15, 2009 at 3:10 AM, Koen Kooi<k.kooi@student.utwente.nl>  wrote:
>> On 15-01-09 08:41, Khem Raj wrote:
>>> On (15/01/09 07:56), Koen Kooi wrote:
>>>> On 15-01-09 07:14, Denys Dmytriyenko wrote:
>>>>
>>>>> 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...
>>>> That's the intended behaviours, since installing the packages will have
>>>> it point to ${libdir}/libvolume.so.0 on your device. I'm not sure if we
>>>> want to patch every package to use relative symlinks.
>>> We would use -dev packages on staged area normally to compile other apps
>>> depending on a given packge if we do not fix the symlink I think it will
>>> try to link to wrong library.
>> We don't use the -dev packages to populate staging :) I keep trying to
>> convince Richard that we should use them, but he keeps coming up with good
>> reasons not to do so :)
>
> Hmm then why do we generate them ?. We do not need these packages on
> target unless we switch to
> native development on target.

SDks and as you say native development (which is getting quite popular 
with the beagleboard folks).

regards,

Koen

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

[Tom Rini]

On Thu, Jan 15, 2009 at 10:53:50AM -0800, Khem Raj wrote:
> On Thu, Jan 15, 2009 at 3:10 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> > On 15-01-09 08:41, Khem Raj wrote:
> >>
> >> On (15/01/09 07:56), Koen Kooi wrote:
> >>>
> >>> On 15-01-09 07:14, Denys Dmytriyenko wrote:
> >>>
> >>>> 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...
> >>>
> >>> That's the intended behaviours, since installing the packages will have
> >>> it point to ${libdir}/libvolume.so.0 on your device. I'm not sure if we
> >>> want to patch every package to use relative symlinks.
> >>
> >> We would use -dev packages on staged area normally to compile other apps
> >> depending on a given packge if we do not fix the symlink I think it will
> >> try to link to wrong library.
> >
> > We don't use the -dev packages to populate staging :) I keep trying to
> > convince Richard that we should use them, but he keeps coming up with good
> > reasons not to do so :)
> 
> Hmm then why do we generate them ?. We do not need these packages on
> target unless we switch to
> native development on target.

SDKs, which oddly DO let you do development vs them, so any problem
stopping us from using them for staging is a problem here.  But that's
all part of another thread RP and I need to start.  Or one of us does,
at least.

-- 
Tom Rini

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

[Koen Kooi]

On 15-01-09 20:20, Tom Rini wrote:
> On Thu, Jan 15, 2009 at 10:53:50AM -0800, Khem Raj wrote:
>> On Thu, Jan 15, 2009 at 3:10 AM, Koen Kooi<k.kooi@student.utwente.nl>  wrote:
>>> On 15-01-09 08:41, Khem Raj wrote:
>>>> On (15/01/09 07:56), Koen Kooi wrote:
>>>>> On 15-01-09 07:14, Denys Dmytriyenko wrote:
>>>>>
>>>>>> 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...
>>>>> That's the intended behaviours, since installing the packages will have
>>>>> it point to ${libdir}/libvolume.so.0 on your device. I'm not sure if we
>>>>> want to patch every package to use relative symlinks.
>>>> We would use -dev packages on staged area normally to compile other apps
>>>> depending on a given packge if we do not fix the symlink I think it will
>>>> try to link to wrong library.
>>> We don't use the -dev packages to populate staging :) I keep trying to
>>> convince Richard that we should use them, but he keeps coming up with good
>>> reasons not to do so :)
>> Hmm then why do we generate them ?. We do not need these packages on
>> target unless we switch to
>> native development on target.
>
> SDKs, which oddly DO let you do development vs them, so any problem
> stopping us from using them for staging is a problem here.  But that's
> all part of another thread RP and I need to start.  Or one of us does,
> at least.

You need things as shlib providers and stamps as well for 
packaged-staging, so using only -dev packages is only part of the solution.

regards,

Koen

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

[Denys Dmytriyenko]

On Thu, Jan 15, 2009 at 10:51:59AM -0500, Denys Dmytriyenko wrote:
> 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.

Otavio was using patched package.bbclass (as mentioned above) for a few days 
and found it working fine and fixing udev issue for him.

Khem, please let me know if you still disagree with the proposed fix. Or if 
anybody else has any objections, please speak up. Otherwise I'd like to check 
in the fix for the package.bbclass in a day or two. Thanks.

-- 
Denys

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

[Otavio Salvador]

Denys Dmytriyenko <denis@denix.org> writes:

>> I guess we need more Core devs to look into this issue to verify the safety of 
>> this patch.
>
> Otavio was using patched package.bbclass (as mentioned above) for a few days 
> and found it working fine and fixing udev issue for him.
>
> Khem, please let me know if you still disagree with the proposed fix. Or if 
> anybody else has any objections, please speak up. Otherwise I'd like to check 
> in the fix for the package.bbclass in a day or two. Thanks.

Yes, I support this patch since it does solve the issue for me.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."

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

[Denys Dmytriyenko]

On Thu, Jan 15, 2009 at 07:57:02PM +0100, Koen Kooi wrote:
> On 15-01-09 19:53, Khem Raj wrote:
>> On Thu, Jan 15, 2009 at 3:10 AM, Koen Kooi<k.kooi@student.utwente.nl>  
>> wrote:
>>> On 15-01-09 08:41, Khem Raj wrote:
>>>> On (15/01/09 07:56), Koen Kooi wrote:
>>>>> On 15-01-09 07:14, Denys Dmytriyenko wrote:
>>>>>
>>>>>> 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...
>>>>> That's the intended behaviours, since installing the packages will have
>>>>> it point to ${libdir}/libvolume.so.0 on your device. I'm not sure if we
>>>>> want to patch every package to use relative symlinks.
>>>> We would use -dev packages on staged area normally to compile other apps
>>>> depending on a given packge if we do not fix the symlink I think it will
>>>> try to link to wrong library.
>>> We don't use the -dev packages to populate staging :) I keep trying to
>>> convince Richard that we should use them, but he keeps coming up with 
>>> good
>>> reasons not to do so :)
>>
>> Hmm then why do we generate them ?. We do not need these packages on
>> target unless we switch to
>> native development on target.
>
> SDks and as you say native development (which is getting quite popular with 
> the beagleboard folks).

Ok, I'm bringing up this old topic, because as was correctly stated, SKDs use 
-dev packages and if we don't fix the symlink pointing to /lib/libvolume.so.0, 
it breaks those SDKs. There is also another side-effect - libvolume-id-dev.ipk 
misses the automatic dependency on libvolume-id0.ipk so the SDK cannot just 
refer to the -dev package and expect the actual library to be installed. In 
that case only the broken link gets installed...

So, if nobody objects, I'm going to apply my first patch from this thread 
against the udev recipe, fixing .so symlink to be relative.

-- 
Denys