Red Hat Bugzilla – Bug 1028169
ABI break caused by a simple rebuild of a package in Fedora 20?
Last modified: 2013-11-08 02:50:19 EST
Created attachment 821291 [details] simple test.c program There is happening something weird with ABI compatibility of rebuilt packages in Fedora 20. The attached test.c demonstrates an issue with libical, one place I noticed (with a help of bug #1023020), but there are surely more such places - probably not only in libical. So, to explain: Current Fedora 20 repositories has two versions of libical available. One is of version 1.0-2, another of version 1.0-3. I also rebuilt 1.0-3 as 1.0-3.1 with no change but increase the version, as a scratch build [1]. Note that none of the rebuilds change API/ABI/SONAME/anything, it's only a new build. Get the test.c program; its first line contains a command to build it. Do these steps: a1) make sure you have installed libical and libical-devel of a version 1.0-2 a2) compile the test program, verify it ends with Success a3) copy the test to test.2 b1) update libical and libical-devel to version 1.0-3 b2) compile the test program, verify it ends with Success b3) copy the test to test.3 b4) run test.2, it fails c1) update libical and libical-devel to version 1.0-3.1, from [1] c2) compile the test program, verify it ends with Success c3) copy the test to test.3.1 c4) run test.2, it fails c5) run test.3, it fails It means, if I run my program with installed the same library as I compiled it in, then it works as expected, but if I run it with updated (or downgraded) version, then it doesn't work (I saw this particular function from libical succeed in some version combination, but it fails in other functions for sure). My question is, how is it possible that the binary change causes failure, even if the package was only rebuilt and nothing else? [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=6151738
Before you ask, I left installed 1.0-3.1 libical and restarted the system, just in case, and the result of c4) and c5) is the same, both tests fail, one compiled against version 2 and the other against version 3.
And why do you think this has anything to do with gcc? Just diff -upr the usr/include trees between the two devel packages, you'll see that there are tons of changes in the icalderivedvalue.h and ical.h headers, including quite randomly reordered enum constants in enum icalvalue_kind (but not limited to just that). Quick skimming of the Makefile.am reveals that this stuff is generated by some perl script from something, so if the perl script or its input isn't guaranteed to generate the same output always and depends on some random other input, you get what you are seeing.
Oh, thanks for a quick response. I didn't expect this being the cause, thus I didn't do the include compare. In that case it might be there for ages, but because of minimal libical updates it wasn't spotted until now.
Alternatively because the cmake rebuild was added with 1.0 release, due to non-updated autotools files. Anyway, I'm going to mark this as a duplicate of the bug from which I added this one. *** This bug has been marked as a duplicate of bug 1023020 ***