On Mon, May 30, 2011 at 01:21:07PM +0200, roucaries bastien wrote: > On Wed, May 25, 2011 at 7:34 PM, Roger Leigh <rleigh@codelibre.net> 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. 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.
Attachment:
signature.asc
Description: Digital signature