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 ? > > If you have multiple copies of libstdc++ loaded, that could cause > some issues. For this reason, it may be that all the C++ parts > need rebuilding against the current version if some parts are using > an old one. Normally this would be enforced by the package > dependencies, but dlopen means this is avoided (which can result > in breakage). Normally it's not good practice to dlopen random > libraries for just this reason--it's normally restricted to > modules within a package, which means the dlopened bits are then > compatible. > > > 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) > > iEYEARECAAYFAk3jhV8ACgkQVcFcaSW/uEj2HwCgxfO9Ppf4EYsbtsGwQpzKYIEN > QpEAniwFaVW8z81OwwvKIeWPxQMUsi9K > =bVA/ > -----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]
