On Mon, May 30, 2011 at 3:06 PM, Roger Leigh <[email protected]> wrote: > On Mon, May 30, 2011 at 02:27:28PM +0200, roucaries bastien wrote: >> On Mon, May 30, 2011 at 1:54 PM, Roger Leigh <[email protected]> wrote: >> > On Mon, May 30, 2011 at 01:21:07PM +0200, roucaries bastien wrote: >> >> On Wed, May 25, 2011 at 7:34 PM, Roger Leigh <[email protected]> wrote: >> >> > On Wed, May 25, 2011 at 12:20:09PM +0200, Bastien ROUCARIES wrote: >> >> >> Hi, >> >> >> >> >> >> I have two strange bug in my package imagemagick. I am really clueless >> >> >> about these.upstream have no idea also. Any help welcome >> >> >> see #625250 >> >> > >> >> > % c++filt _ZNSt14error_categoryD2Ev >> >> > std::error_category::~error_category() >> >> > >> >> > % nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt14error_categoryD2Ev >> >> > 0000003380272800 T _ZNSt14error_categoryD2Ev >> >> > >> >> > % nm -C -D /usr/lib/libstdc++.so.6 | grep error_category >> >> > 0000003380272800 T std::error_category::~error_category() >> >> > >> >> > This is on a sid system. >> >> > >> >> > On squeeze: >> >> > $ nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt14error_categoryD2Ev >> >> > $ echo $? >> >> > 1 >> >> > >> >> > If imagemagick was built against the current libstdc++ and run >> >> > using an older libstdc++ without the symbol, you will get this >> >> > error. >> >> > >> >> > I don't see any direct libstdc++ dependency in either the >> >> > imagemagick package, or its library needed sections. What's using >> >> > libdjvulibre? Is it being dlopened. >> >> >> >> Yes it is dlopened >> >> >> >> > If this is the case, >> >> > libdjvulibre is using an old version of libstdc++, and that's an >> >> > issue with its dependencies (and/or the libstdc++ symbol >> >> > versioning). >> >> >> >> Seems so, more strangely using LD_PRELOAD=/usr/lib64/libdjvulibre.so >> >> or LD_BIND_NOW=1 fix this issue. Will reassign to libdvu >> > >> > This library may just require a rebuild. You could request a >> > binNMU to get it rebuilt if this is the case. >> > >> >> > You'll need a full stack trace to work out what's using this >> >> > library if you haven't done so already. >> >> >> >> It does not coredump. How can I get a backtrace ? using LD_DEBUG=all >> >> option point to libdjvu >> > >> > Well, you can get a backtrace at any point, not just on coredump. >> > You could 'break dlopen' to stop and get a backtrace at all dlopen >> > calls. Or on any function call you like. This will let you find >> > out what's responsible for the dlopen in the first place. >> >> It break in __libc_start_main >> _start >> >> Any idea ? > > No. You'll need to look at the backtrace at that point. It may > be irrelevant; just continue and look at all the break points, > inspecting the backtrace each time. > > Note that ELF contructors (.init section) run early before main() > is called. They can do arbitrary stuff.
I think it is this case, at break at exit and backtrace show me this. Message about missing symbol was already printed. > > > Regards, > Roger > > -- > .''`. Roger Leigh > : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ > `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ > `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk3jlkwACgkQVcFcaSW/uEgCmACdGhpAcZJa3Z9mO4NAyqnQ3MwQ > g5oAn1yvyTcLHN1slm3jbuGm1nPIfFJ0 > =O9CN > -----END PGP SIGNATURE----- > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
