Bug 1028169

Summary: ABI break caused by a simple rebuild of a package in Fedora 20?
Product: [Fedora] Fedora Reporter: Milan Crha <mcrha>
Component: libicalAssignee: Robert Scheck <redhat-bugzilla>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 20CC: jakub, law, mcrha, rdieter, redhat-bugzilla, sgallagh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-08 07:50:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1023020    
Attachments:
Description Flags
simple test.c program none

Description Milan Crha 2013-11-07 19:59:44 UTC
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 20:06:51 UTC
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 23:37:31 UTC
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 07:48:54 UTC
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 07:50:19 UTC
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 ***