dbus programs will not use nosegneg libraries

Confirmed with ami-fa658593 canonical-alphas-us/karmic-i386-alpha6.manifest.xml

Well, that's intriguing. I'll look into this (because I'm intrigued), but I'm declining the karmic nomination because the largest practical impact of the bug is the dmesg output itself - these dbus utilities represent an infinitesimal use of the system, if they run a little slower because of negative segments it's not going to significantly impact the instance performance.

On Sat, 19 Sep 2009, Steve Langasek wrote:

> Well, that's intriguing. I'll look into this (because I'm intrigued),
> but I'm declining the karmic nomination because the largest practical
> impact of the bug is the dmesg output itself - these dbus utilities
> represent an infinitesimal use of the system, if they run a little
> slower because of negative segments it's not going to significantly
> impact the instance performance.

I agree. I don't think its a big issue, the warning is just annoying. I
think in general, though, linking with rpath is not preferred, as, shown
here, it overrides system runtime settings.

On Sat, Sep 19, 2009 at 04:33:09PM -0000, Scott Moser wrote:

> I agree. I don't think its a big issue, the warning is just annoying. I
> think in general, though, linking with rpath is not preferred, as, shown
> here, it overrides system runtime settings.

Have you tried removing the rpath from the binaries (using 'chrpath -d') to
confirm that this is the cause of the problem?

The rpath that I see listed in the binaries is the current package version
is //lib. I don't see how that could cause such inconsistent behavior.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I was previously unfamiliar with chrpath. making that change does indeed fix the problem (at least as reported by ldd). I ran the following on ami-fa658593 (i386 alpha6 ec2)

$ dpkg-query --show dbus
dbus 1.2.16-0ubuntu4
$ list="/bin/dbus-uuidgen /usr/bin/dbus-monitor /usr/bin/dbus-send"
$ for x in ${list}; do echo $x; ldd $x | grep "cmov" || echo " None"; done
/bin/dbus-uuidgen
   libc.so.6 => //lib/tls/i686/cmov/libc.so.6 (0xb7d68000)
   libpthread.so.0 => //lib/tls/i686/cmov/libpthread.so.0 (0xb7d4e000)
   librt.so.1 => //lib/tls/i686/cmov/librt.so.1 (0xb7d44000)
<snip identical for /usr/bin/dbus-monitor, /usr/bin/dbus-send>

$ sudo chrpath ${list}
/bin/dbus-uuidgen: RPATH=//lib
/usr/bin/dbus-monitor: RPATH=//lib
/usr/bin/dbus-send: RPATH=//lib
$ sudo chrpath -d ${list}
$ for x in ${list}; do echo $x; ldd $x | grep "cmov" || echo " None"; done
/bin/dbus-uuidgen
  None
/usr/bin/dbus-monitor
  None
/usr/bin/dbus-send
  None

should have put this in the previous message. After removing rpath and rebooting the instance, dmesg no longer shows the error.

This is also a glibc bug; glibc should not fail to properly resolve hwcap directories in the presence of an rpath, regardless of how goofy said rpath is.

This bug was fixed in the package dbus - 1.2.16-0ubuntu6

---------------
dbus (1.2.16-0ubuntu6) karmic; urgency=low

  * Use --exec-prefix='', not --exec-prefix=/, so that we get libdir=/lib
    instead of libdir=//lib - avoiding the incorrect setting of rpath in the
    dbus helper utils. LP: #432718.

 -- Steve Langasek <email address hidden> Tue, 22 Sep 2009 15:05:19 -0700

verified that Steve's fix in comment 8 fixes this problem.

on alpha6 i386 (ami-fa658593):
# fresh instance
$ dmesg | grep Offending
[ 2.538665] ** Offending process: dbus-uuidgen (pid=1159) **
$ sudo apt-get update && sudo apt-install dbus
$ dpkg-query --show dbus
dbus 1.2.16-0ubuntu6
$ sudo reboot
...
$ $ dmesg | grep "Offending" || echo fixed
fixed