Bastien ROUCARIES writes: > On Sun, Jan 18, 2009 at 11:43 PM, Bastien ROUCARIES > <roucaries.bast...@gmail.com> wrote: > > On Sun, Jan 18, 2009 at 11:32 PM, Matthias Klose <d...@cs.tu-berlin.de> > > wrote: > >> Package: djvulibre > >> Version: 3.5.21-3 > >> Severity: serious > >> Tags: patch > >> > >> http://patches.ubuntu.com/d/djvulibre/djvulibre_3.5.21-3ubuntu1.patch > >> > >> djvulibre hardcodes knowledge about atomic builtins, and on which > >> architectures these can be found, and doesn't rely on a autoconf > >> test. gcc-4.3_4.3.2-2 now got these kernel helpers for armel and > >> hppa. For armel these builtins have to be linked into the shared > >> library. A workaround can be found in the above patch. Please let me > >> know if a NMU is wanted. > > > > I believe best thing to do is to forward to upstream. A autoconf test > > will be better. > > > BTW what the f***k of linking with libsupc++ ???
please calm down. > According to web doc: > > What's libsupc++? > > > > > >If the only functions from libstdc++.a which you need are language support > >functions (those listed in clause 18 of the standard, e.g., new and delete), > >then try >linking against libsupc++.a, which is a subset of libstdc++.a. > >(Using gcc instead of g++ and explicitly linking in libsupc++.a via -lsupc++ > >for the final link step >will do it). This library contains only those > >support routines, one per object file. But if you are using anything from > >the rest of the library, such as IOStreams or >vectors, then you'll still > >need pieces from libstdc++.a. > > > > And libgcc is automagically added to gcc. > > Could you send us the buildlog ? I suppose it is not really a good method hmm, I don't have the log of the failed build anymore. looks like linking with -lgcc is sufficient. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
