--- En date de : Jeu 23.6.11, Caolán McNamara <caol...@redhat.com> a écrit :
> De: Caolán McNamara <caol...@redhat.com> > Objet: Re: [Libreoffice] Debug compilation fails in sal module > À: "Julien Nabet" <serval2...@yahoo.fr> > Cc: libreoffice@lists.freedesktop.org > Date: Jeudi 23 juin 2011, 12h42 > On Wed, 2011-06-22 at 21:52 +0200, > Julien Nabet wrote: > > Le 22/06/2011 13:55, Caolán McNamara a écrit : > > > On Tue, 2011-06-21 at 23:18 +0200, Julien Nabet > wrote: > > >> I'm completely stucked, could it be a bug in > one of the C++ libraries of > > >> Debian testing ? > ... > > I'm going to take a look at it and hope to find > something. > > Address 0x482bcd0 is 0 bytes inside data symbol > "_ZGVNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE" > > c++filt > _ZGVNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE > > guard variable for std::num_get<char, > std::istreambuf_iterator<char, > std::char_traits<char> > >::id > > so that's completely nuts I think, so... > > I wonder. Can you give me the output of... > > md5sum solver/350/unxlngi6/lib/libstdc++.so.6 > and > md5sum /usr/lib/libstdc++.so.6 to make sure they match. > I saw this output for Valgrind and I thought about comparing osl_process.cxx in unx part with equivalent Windows part. I remarked that in unx part string_container_t was a vector of std::string + something. In Windows, it was a list of OUString + something For the md5, I'll do that as soon as I get home. I'm curious to know if I'm the only one to have this problem with debug compilation. About rm -rf sal/unxlng, I did that everytime since it's quick to recompile this whole part. But about solenv Debug, I'll take a look. Julien. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
