[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#720063: RFS: capnproto/0.2.0-1 [ITP] -- Tool for working with the Cap'n Proto data interchange format



Kenton (upstream maintainer) has narrowed this down to a compiler bug that only occurs during a build without the -DNDEBUG flag set. Typically the NDEBUG flag is set if CXXFLAGS are left unspecified, but the Debian build scripts obviously meddle with those a little. To work around this, I've explicitly added the -DNDEBUG flag in via DEB_CXXFLAGS_MAINT_APPEND.

Unclear whether this is an upstream issue in GCC or a bug in Debian/Ubuntu patches. Kenton reproduced this with Ubuntu's patches against 4.8, so evidence seems to hint at upstream -- though Ubuntu is probably using many of the Debian patches too, I guess.

Also incorporated part of an upstream patch for another potential, seemingly unrelated memory corruption issue that didn't quite make the 0.2.0 release.

Let me know if you still can't build from source with these two changes in place.

I've also explicitly removed the .symbols file as I found the Policy Manual explicitly talks about C++ libraries in the last paragraph of section 8.6 (http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-depends):

"symbols files are therefore recommended for most shared library packages since they provide more accurate dependencies. For most C libraries, the additional detail required by symbols files is not too difficult to maintain. However, maintaining exhaustive symbols information for a C++ library can be quite onerous, so shlibs files may be more appropriate for most C++ libraries."

I've already got a shlibs file in place for libcapnp-0.2.0, so I think that's enough.

Last of all, I've just built & uploaded a new build of 0.2.0-1 with the changes you suggested in your original review, plus the changes discussed in this email:

http://mentors.debian.net/debian/pool/main/c/capnproto/capnproto_0.2.0-1.dsc

Thanks! Please let me know if I can do anything else to move this forward.

-- 
Tom Lee / http://tomlee.co / @tglee

Reply to: