Please advise for forthcoming bug report

[Émeric Maschino]

Hi,

I found a week ago what's causing gnome-settings-daemon to fail to
connect to DBUS session and eat 100% CPU on IA-64 architecture (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537572 for details).

The problem was introduced with gnome-settings-daemon-2.24.1-1. It
isn't a problem with the source code per se, but with the flags passed
to ld by the debian/rules script of the gnome-settings-daemon-2.24.1-1
source package. Indeed, starting with gnome-settings-daemon-2.24.1-1,
the debian/rules script contains the following line:

LDFLAGS += -Wl,-O1 -Wl,-z,defs -Wl,--warn-unresolved-symbols -Wl,--as-needed

The culprit is the -Wl,-z,defs flags which produces a broken binary.
Simply removing this flag produces a working binary (tested with
gnome-settings-daemon-2.24.1-1 and current Debian Testing
gnome-settings-daemon-2.30.2-2). I've also double-checked that adding
this flag to the debian/rules script of the
gnome-settings-daemon-2.22.2.1-2 source package leads to a broken
binary, whereas the official one, without this flag, is working
properly.

What's unclear to me is whether this problem is specific to
gnome-settings-daemon or reveals something broken with ld, perhaps
only limited to the IA-64 architecture. In short, should I add
additional information to bug #537572 about gnome-settings-daemon (and
what to ask for? The removal the offending ld flags? I bet that all
other architectures will thus be impacted, so surely not the right way
to fix the problem) or open a new bug report against binutils in order
to investigate whether ld is working properly?

In the background, a broken gnome-settings-daemon will be very
problematic with GNOME3 on Wheezy, as additional gnome-settings-daemon
processes are forked each time a user log in and log on. And
unfortunately, this user doesn't have enough priviledges to kill the
faulty gnome-settings-daemon, thus leading to a completely unusable
system with several gnome-settings-daemon instances eating as much CPU
as they can.

Best regards,

     Émeric