I've created a 2.2.0a release: SVN: http://protobuf.googlecode.com/svn/tags/2.2.0a/ tarball: http://groups.google.com/group/protobuf/web/protobuf-2.2.0a.tar.bz2 Diff from 2.2.0: http://code.google.com/p/protobuf/source/detail?r=246
I will make it live on the official site as soon as you confirm that it fixes the problem. On Wed, Nov 18, 2009 at 4:41 PM, Kenton Varda <ken...@google.com> wrote: > Bumping the soname is part of our release process, since C++ ABI > compatibility is practically impossible to maintain. Unfortunately, if SVN > is to be believed, it appears that somehow this didn't happen with the 2.2.0 > release. And here I thought I had finally done a release without screwing > anything up! > > I guess I will do a 2.2.0a which does nothing but fix this. I'd like to > avoid changing the last digit there because it would create a bunch of new > ways that I could screw up. > > On Wed, Nov 18, 2009 at 3:55 PM, Robert Edmonds <edmo...@debian.org>wrote: > >> [ kenton varda, upstream release engineer for protobuf, added to Cc. ] >> >> Dirk Eddelbuettel wrote: >> > I am not sure what the best way forward is. Given that mumble is the >> only >> > user of protobuf, could you just rebuild based on the protobuf? That is >> > probably quicker than a new upload, NEW queue, required rebuild, ... and >> > avoids all hazzles regarding soname conflicts if we move to 5 now and >> Google >> > later claims 5. >> >> since the changes from 2.1.0 to 2.2.0 have demonstrably broken ABI >> compatibility, the SONAME really should be bumped, regardless of NEW >> delays, etc. because it is the correct thing to do, rather than breaking >> unrelated software. ideally it should be coordinated with upstream so >> that we don't break binary compatibility with other linux distributions >> (to the extent that this is possible with the C++ ABI, which i am not >> especially familiar with). >> >> kenton, is it possible to make a 2.2.1 release with just a SONAME bump? >> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556563 for the >> relevant justification: >> >> m...@exez:~$ mumble >> mumble: Symbol `_ZTIN6google8protobuf7MessageE' has different size in >> shared object, consider re-linking >> mumble: symbol lookup error: mumble: undefined symbol: >> _ZN6google8protobuf14MessageFactory29InternalRegisterGeneratedFileEPKcPFvvE >> >> i've also noticed that these changes break the protobuf-c package (for >> which i am the debian maintainer): >> >> edmo...@chase{0}:~$ protoc-c >> protoc-c: symbol lookup error: /usr/lib/libprotoc.so.4: undefined >> symbol: _ZN6google8protobuf8internal10WireFormat21kWireTypeForFieldTypeE >> >> i think protobuf-c and mumble are the only two reverse dependencies of >> protobuf, and they're both broken by the 2.2.0-0.1 upload. >> >> the protobuf debian package unfortunately lacks .symbols files for >> libprotocN and libprotobufN, which would have caught this problem. >> when .symbols files are in use, the package build should fail if there >> are any symbol insertions or deletions. >> >> i've rebuilt the debian protobuf 2.1.0-1 package, adding symbol files, >> and then used the result to rebuild the 2.2.0-0.1 package, which reveals >> that there are quite a few missing symbols in 2.2.0: >> >> edmo...@chase{0}:~/debian/protobuf/symbols/protobuf-2.2.0/debian$ grep >> _ZN6google8protobuf14MessageFactory29InternalRegisterGeneratedFileEPKcPFvvE >> *.symbols >> libprotobuf4.symbols:#MISSING: 2.2.0# >> _zn6google8protobuf14messagefactory29internalregistergeneratedfileepkcpf...@base2.1.0 >> >> (the missing symbol that broke mumble.) >> >> edmo...@chase{0}:~/debian/protobuf/symbols/protobuf-2.2.0/debian$ grep >> MISSING *.symbols | wc -l >> 311 >> >> (310 other symbols are missing as well.) >> >> i've attached the revelant diff.gz's. >> >> btw, 2.2.0 introduced a new 'libprotobuf-lite' library which should be >> split out of the libprotobuf binary package, since (i gather) the idea >> is to have a lite version of the library which doesn't require the full >> heft of libprotobuf. >> >> -- >> Robert Edmonds >> edmo...@debian.org >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >> >> iEYEARECAAYFAksEiVcACgkQdp+/SHMBQJFXTQCgi8udEma1ccxxzHxMw4RPcjT/ >> 7e8An3+4He41DprUK0BefB/hdWLncwag >> =3+hv >> -----END PGP SIGNATURE----- >> >> >
