From: Patrick O. <pat...@gm...> - 2013-11-22 09:07:11
|
Hello! The recent issue with inconsistent ABIs in Fedora [1,2] because enums were assigned randomly in the header files makes me wonder: if these header files contain enums sorted alphabetical, as they do now, how can new entries be added? It looks to me that every small change, like adding a new parameter, will now lead to a new ABI for libical. In case it is not obvious: this is very bad for compatibility of binaries with different Linux. SyncEvolution binaries from syncevolution.org currently no longer work with distros which switched to libical 1.0 because the soname changed from libical.so.0 to libical.so.1. Can this be avoided in the future? For example, can the header file be considered frozen again from now on, with new enum values added manually at the end of each enumeration? The rest of the code could still be auto-generated during each compile run, just the header files need to remain the same. [1] http://sourceforge.net/p/freeassociation/code/1156/ [2] http://sourceforge.net/p/freeassociation/code/1156/ -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
From: Allen W. <wi...@kd...> - 2013-11-23 15:12:54
|
On Friday, November 22, 2013 10:07:00 AM Patrick Ohly wrote: > Hello! > > The recent issue with inconsistent ABIs in Fedora [1,2] because enums > were assigned randomly in the header files makes me wonder: if these > header files contain enums sorted alphabetical, as they do now, how can > new entries be added? > > It looks to me that every small change, like adding a new parameter, > will now lead to a new ABI for libical. In case it is not obvious: this > is very bad for compatibility of binaries with different Linux. > SyncEvolution binaries from syncevolution.org currently no longer work > with distros which switched to libical 1.0 because the soname changed > from libical.so.0 to libical.so.1. > > Can this be avoided in the future? > > For example, can the header file be considered frozen again from now on, > with new enum values added manually at the end of each enumeration? The > rest of the code could still be auto-generated during each compile run, > just the header files need to remain the same. > > [1] http://sourceforge.net/p/freeassociation/code/1156/ > [2] http://sourceforge.net/p/freeassociation/code/1156/ > But this was a major release, so reasonable and not unexpected for ABI to break in a major release. Of course we need to find a way to ensure ABI. Now I worried that ABI is broken again for people who rebuilt against 1.0.0 and then install the next release. So I'm thinking of reverting 1156 |
From: Patrick O. <pat...@gm...> - 2013-11-23 18:57:24
|
On Sat, 2013-11-23 at 10:12 -0500, Allen Winter wrote: > But this was a major release, so reasonable and not unexpected for ABI to break in a major release. I agree, if there are good reasons for an ABI break, then doing it at a major release is the right thing to do. But that doesn't mean that a major release alone is a reason for breaking the ABI. > Of course we need to find a way to ensure ABI. Good. > Now I worried that ABI is broken again for people who rebuilt against 1.0.0 > and then install the next release. So I'm thinking of reverting 1156 And restore the previous behavior where the ABI was essentially undefined, because it was depending on the implementation of Perl? That doesn't sound like a solution. I had checked, Ubuntu Saucy has libical.so.1 with enums sorted, just like Fedora has now. I suggest declaring that as the libical.so.1 ABI and ensuring that all users of libical 1.0 adhere to that; therefore a bugfix release with commit 1156 would be good. -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |
From: Patrick O. <pat...@gm...> - 2014-02-04 12:56:42
|
On Sat, 2013-11-23 at 19:57 +0100, Patrick Ohly wrote: > On Sat, 2013-11-23 at 10:12 -0500, Allen Winter wrote: > > But this was a major release, so reasonable and not unexpected for ABI to break in a major release. > > I agree, if there are good reasons for an ABI break, then doing it at a > major release is the right thing to do. But that doesn't mean that a > major release alone is a reason for breaking the ABI. > > > Of course we need to find a way to ensure ABI. > > Good. > > > Now I worried that ABI is broken again for people who rebuilt against 1.0.0 > > and then install the next release. So I'm thinking of reverting 1156 > > And restore the previous behavior where the ABI was essentially > undefined, because it was depending on the implementation of Perl? That > doesn't sound like a solution. > > I had checked, Ubuntu Saucy has libical.so.1 with enums sorted, just > like Fedora has now. I suggest declaring that as the libical.so.1 ABI > and ensuring that all users of libical 1.0 adhere to that; therefore a > bugfix release with commit 1156 would be good. Do we agree that libical.so.1 uses the ABI with sorted enums and that therefore all distros should compile libical 1.0 with commit 1156 included? I'm copying kub...@li..., the maintainers of libical in Ubuntu, to ensure that they are aware of this issue. BTW, I was wrong when I said earlier that no relevant changes happened between libical.so.0 and libical.so.1 as far as SyncEvolution was concerned. Inserting ICAL_ACKNOWLEDGED_PROPERTY at the beginning of the icalproperty_kind enum changed values that SyncEvolution uses, so I'll have to add further hacks to keep the same binary working with dlopened libical.so.1 and libical.so.0. -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |