The libs in this packages doesn't seem to be compiled with --enable-debug=yes

I'm saying this because you can trigger debug messages for GObject and signals by
doing a g_type_init_with_debug_flags () in the beginning of your prog or by
setting the environment variable GOBJECT_DEBUG to "objects" and/or "signals"
(see docs/debugging.txt for details).

I have compiled glib myself with --enable-debug=yes and this debug mechanism
works.

Could you confirm --enable-debug=yes wasn't used ?
And if so, use it next time :-)

Thanks,

Regards,
Fred.

severity 170726 minor
thanks
FL> Version: 2.0.7-1

FL> The libs in this packages doesn't seem to be compiled with --enable-debug=yes

First, default value shipped by the upstream is minimum, but
not no. Second, I committed an offense with libgtk1.2
ago. debug'ed libraries and non-debug'ed libraries was
incompatible, and it broke an ABI. if possible, this changes
is not useful as a debug package, because when this debug
package is used, the developer might get an another
problem. it will be called as enbug package ;)

Anway I need to check whether an ABI is broken or not.

What about using --enable-debug=yes only in libglib2.0-dbg ?

        Hi,

 This is a followup for Debian bug <http://bugs.debian.org/170726>.

 Glib is currently built with optimizations and this results in libs
 which are copied into libglib2.0-0 and stripped, and in debug files
 (which are basically the delta between stripped and unstripped
 binaries) in libglib2.0-dbg.

 Would we build glib2.0 twice, one time with optimizations, the second
 time with --enable-debug, this would result in different libraries, and
 you wouldn't experience the same bugs with the two libraries (some bugs
 might disappear or appear dur to debugging symbols); this would also
 mean we have no useful symbols for the optimized library.

 Hence, I don't think we can do anything better than we currently have,
 and I'm inclined to close this bug, but please speak up if you have a
 better idea!

   Bye,