V Tue, Nov 28, 2023 at 12:24:45PM +0100, Dodji Seketeli napsal(a): > Daniel P. Berrangé <berrange@xxxxxxxxxx> a écrit: > > > On Mon, Nov 27, 2023 at 04:20:16PM +0100, Fabio Valentini wrote: > >> On Fri, Nov 24, 2023 at 12:08 PM David King <amigadave@xxxxxxxxxxxxx> wrote: > >> > > >> > The latest released versions of libxml2 have a couple of important > >> > changes in header files that have unintentionally caused some packages > >> > to fail to build without modification, including: > >> > > >> > * several functions now accept or return a const xmlError struct > >> > * cyclic dependencies in header files were fixed (by dropping some > >> > includes) > >> > >> Sorry if the answer to this question is obvious - but shouldn't > >> breaking changes like these cause an soname bump? > >> I realize the whole "unintentional" part - but if these changes also > >> affect ABI (the first sounds like it might do that), dependent > >> packages would need to be rebuilt either way, wouldn't they? > > > > IIUC, the changes in libxml2 are API breaks, but not ABI breaks. > > > > ie the 'xmlError' parameter should have been const all along, > > and apps would have been using it as if it were const. The > > API was changed to correct this mistake and should be backcompat > > with an pre-existing compiled app, but cause warnings on new > > builds. Annoying, but an acceptable change without soname bump. > > For what it's worth, the ABI compatibility verifier caught this change > between libxml2.so.2.11.5 and libxml2.so.2.12.0 and categorized it as > being "ABI compatible" (i.e, not incompatible/breaking) at: > https://artifacts.dev.testing-farm.io/b7d369b0-f288-4564-a331-48492c20bf8c/: > > [C] 'function int xmlCopyError(xmlErrorPtr, xmlErrorPtr)' at error.c:985:1 has some indirect sub-type changes: > parameter 1 of type 'typedef xmlErrorPtr' changed: > entity changed from 'typedef xmlErrorPtr' to compatible type 'const xmlError*' > in pointed to type 'struct _xmlError': > entity changed from 'struct _xmlError' to 'const _xmlError' > type size hasn't changed > > I guess the important bit here is "entity changed from 'struct _xmlError' to 'const _xmlError'". > > So, yes, this is not an ABI incompatible change. > Well abidiff for createrepo_c <https://artifacts.dev.testing-farm.io/3a97fed7-84b8-4220-9a7b-9f988dd8cd90/work-rpminspectud7bmqxi/rpminspect/execute/data/guest/default-0/rpminspect-1/data/viewer.html> complains: underlying type 'xmlParserCtxt*' changed: in pointed to type 'typedef xmlParserCtxt' at tree.h:40:1: underlying type 'struct _xmlParserCtxt' at parser.h:181:1 changed: type size changed from 3840 to 3968 (in bits) 4 data member insertions: 'unsigned int maxAmpl', at offset 3840 (in bits) at parser.h:323:1 'xmlParserNsData* nsdb', at offset 3872 (in bits) at parser.h:325:1 'unsigned int attrHashMax', at offset 3904 (in bits) at parser.h:326:1 'xmlAttrHashBucket* attrHash', at offset 3936 (in bits) at parser.h:327:1 1 data member changes (5 filtered): type of 'int* attallocs' changed: in pointed to type 'int': type name changed from 'int' to 'unsigned int' type size hasn't changed While most (all?) libxml2 functions pass a pointer to xmlParserCtxt, a definition of the xmlParserCtxt structure is open to anybody in <libxml/parser.h>. That means an application built against old libxml2 can construct a different structure than libxml2 expects. That is called an ABI breakage. -- Petr
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
