GNOME Bugzilla – Bug 755550
ABI break without soname bump
Last modified: 2015-10-08 09:15:47 UTC
Version 2.6.0 dropped the sigc::lambda selectors. The NEWS file mentions that this is not an ABI break, but actually it is. Compiling a small test program using 2.4, then upgrading to 2.6 results in ./test: symbol lookup error: ./test: undefined symbol: _ZN4sigc2_2E libsigc++ needs to bump the soname in that case. // test program #include <iostream> #include <sigc++/sigc++.h> int main() { std::cout << sigc::_1(10,20,30) << std::endl; return 0; }
Re-adding the symbols and quickly doing a 2.6.2 release looks like the best way forward to me. Then in the 3.20 development cycle one can drop those deprecated symbols and properly bump the soname.
Created attachment 312161 [details] [review] patch: Recreate adaptors/lambda files necessary not to break ABI Here's a patch that solves the problem. I've tested with the small program in comment 0, and with the old test_lambda.cc in libsigc++. Built the programs with libsigc++ 2.4.0, then executed them with the newest libsigc++, including the attached patch. And yes, without the patch execution failed. Does anyone else want to test the patch before I push it? This is all my fault. I made some tests, described in bug 672555 comment 21. I must have messed up the tests in some way. I got the impression that the lambda functions in libsigc++ did not create any symbols in the .so file that application programs reference. Unfortunately, I was wrong.
Created attachment 312179 [details] [review] patch: Recreate adaptors/lambda files necessary not to break ABI Here's an alternative patch. I prefer this one. The extern declarations of sigc::_1 .. sigc::_7 have been moved to lambda.cc, to keep them out of the API. All lambda code is excluded from the documentation. Now I know what was wrong with the tests in bug 672555 comment 21. I had used libsigc++'s make and make check commands to build test_lambda.cc. Then g++ is invoked with the -O2 optimization option. With that optimization level, the generated code does not require the sigc::_1 .. sigc::_7 symbols in the .so file. I suppose the compiler inlines more when it optimizes the code.
Thanks. Please go for it. Maybe add a comment pointing at this but report and/or the commit so we can easily remove this in some ABI-breaking version one day. Thanks for finding this, Michael. Out of interest, where did these appear in the ABI of the rest of the API? I mean, how did the missing ABI affect some simple test code?
Review of attachment 312179 [details] [review]: I have pushed the patch with an added comment that refers to this bug report from lambda.cc.m4. https://git.gnome.org/browse/libsigc++2/commit/?id=910a3e3044dfd78887019b469d592028ce8a2593 I keep the bug open until a new release has been made. I haven't time to do that today. Murray, if you want to do it now, it's ok with me.
Thanks. I've just released libsigc++ 2.6.1. And thanks to Michael for finding this. I'm still interested to know what part of the non-deprecated ABI was affected.
No part of non-deprecated ABI or API is affected. The test code in comment 0 contains the deprecated lambda function sigc::_1. In bug 672555 comment 21 I tested that function and other libsigc++ lambda functions in the deprecated, and now removed, libsigc++2/tests/test_lambda.cc. I drew the erroneous conclusion that no lambda functions require ABI. That conclusion is true for g++ with -O2 optimization, but it's not true for g++ without optimization. Applications that have been built without optimization against libsigc++ 2.4.x or earlier may require the name-mangled sigc::_1 .. sigc::_7 symbols in the .so file. You forgot to push the changes to the git repository, when you released libsigc++ 2.6.1.
Ah, yes, now I remember. Thanks, and I've pushed the changes now.
@Murray: In Debian we use so called .symbols files to track which symbols are exported by a library [1]. When packaging 2.6.0, I noticed that the following symbols were dropped: _ZN4sigc2_1E@Base _ZN4sigc2_2E@Base _ZN4sigc2_3E@Base _ZN4sigc2_4E@Base _ZN4sigc2_5E@Base _ZN4sigc2_6E@Base _ZN4sigc2_7E@Base A quick search using codesearch.debian.net showed that we actually have consumers of that API/ABI and there might also be other projects which are not shipped in Debian, thus not covered in codesearch.debian.net. [1] https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
Thanks, Michael. Can that also show you the demangled C++ symbols? Is this resolved for you now?
I used c++filt to demangle the names