Bug 1028169 - ABI break caused by a simple rebuild of a package in Fedora 20?
ABI break caused by a simple rebuild of a package in Fedora 20?
Status: CLOSED DUPLICATE of bug 1023020
Product: Fedora
Classification: Fedora
Component: libical (Show other bugs)
20
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Robert Scheck
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1023020
  Show dependency treegraph
 
Reported: 2013-11-07 14:59 EST by Milan Crha
Modified: 2013-11-08 02:50 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-08 02:50:19 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
simple test.c program (768 bytes, text/plain)
2013-11-07 14:59 EST, Milan Crha
no flags Details

  None (edit)
Description Milan Crha 2013-11-07 14:59:44 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
Comment 1 Milan Crha 2013-11-07 15:06:51 EST
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.
Comment 2 Jakub Jelinek 2013-11-07 18:37:31 EST
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.
Comment 3 Milan Crha 2013-11-08 02:48:54 EST
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.
Comment 4 Milan Crha 2013-11-08 02:50:19 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.