From: Lutz <lu...@us...> - 2005-04-15 18:32:51
|
On Fri, 2005-04-15 at 19:28 +0200, Hongli Lai wrote: > Hi. I'm building an autopackage[1] for Gimp, and I came across a problem > with libexif: the library major has changed compared to the one shipped > with slightly older distributions, such as Fedora Core 1. This means > that libexif broke compatibility. or that no-one has educated libexif developers (specifically me) sufficiently on how to correctly set up and maintain libexif/configure.in. My goal up to now was to make sure that we don't release different incompatible versions of libexif with the same major version. It seems that I've fully reached that goal :-) If I remember correctly, the last change breaking binary compatibility happened in July 2002. After that, we only added interfaces and fixed the code behind the existing API. There is some logic and documentation in libexif/configure.in that is probably incorrect or (at least) not clear enough. Up to now, if I added an interface, I just increased 'CURRENT'. See code snippet below. Could you send us a patch? Thanks a lot! Regards Lutz dnl --------------------------------------------------------------------------- dnl Versioning: dnl - AGE (Micro): Increment if any interfaces have been added; set to 0 dnl if any interfaces have been removed. Removal has dnl precedence over adding, so set to 0 if both happened. dnl - REVISION (Minor): Increment any time the source changes; set to dnl 0 if you incremented CURRENT. dnl - CURRENT (Major): Increment if the interface has additions, changes, dnl removals. dnl --------------------------------------------------------------------------- LIBEXIF_AGE=0 LIBEXIF_REVISION=0 LIBEXIF_CURRENT=12 AC_SUBST([LIBEXIF_AGE]) AC_SUBST([LIBEXIF_REVISION]) AC_SUBST([LIBEXIF_CURRENT]) LIBEXIF_VERSION_INFO=`expr $LIBEXIF_CURRENT + $LIBEXIF_REVISION`: $LIBEXIF_AGE:$LIBEXIF_REVISION AC_SUBST([LIBEXIF_VERSION_INFO]) |
From: Hongli L. <h....@ch...> - 2005-04-15 19:13:16
Attachments:
diff
|
Lutz Müller wrote: > or that no-one has educated libexif developers (specifically me) > sufficiently on how to correctly set up and maintain > libexif/configure.in. > > My goal up to now was to make sure that we don't release different > incompatible versions of libexif with the same major version. It seems > that I've fully reached that goal :-) > > If I remember correctly, the last change breaking binary compatibility > happened in July 2002. After that, we only added interfaces and fixed > the code behind the existing API. > > There is some logic and documentation in libexif/configure.in that is > probably incorrect or (at least) not clear enough. Up to now, if I added > an interface, I just increased 'CURRENT'. See code snippet below. Could > you send us a patch? > > Thanks a lot! > > Regards > > Lutz > > > dnl > --------------------------------------------------------------------------- > dnl Versioning: > dnl - AGE (Micro): Increment if any interfaces have been added; > set to 0 > dnl if any interfaces have been removed. Removal > has > dnl precedence over adding, so set to 0 if both > happened. > dnl - REVISION (Minor): Increment any time the source changes; set to > dnl 0 if you incremented CURRENT. > dnl - CURRENT (Major): Increment if the interface has additions, > changes, > dnl removals. > dnl > --------------------------------------------------------------------------- > LIBEXIF_AGE=0 > LIBEXIF_REVISION=0 > LIBEXIF_CURRENT=12 > AC_SUBST([LIBEXIF_AGE]) > AC_SUBST([LIBEXIF_REVISION]) > AC_SUBST([LIBEXIF_CURRENT]) > LIBEXIF_VERSION_INFO=`expr $LIBEXIF_CURRENT + $LIBEXIF_REVISION`: > $LIBEXIF_AGE:$LIBEXIF_REVISION > AC_SUBST([LIBEXIF_VERSION_INFO]) Ok, so the problem is that you don't understand libtool versioning correctly. You should read 'info libtool' -> section Versioning. If you add an interface, and don't change anything in the old interfaces which could break applications (this includes function semantics), then you are supposed to increase AGE, not CURRENT. So the comment is wrong too. Only if you did something that breaks binary compatibility, AGE should incremented. I attached a one-liner patch which fixes the comments. I won't touch the numbers because the damage has already been done. :( Is libexif 0.5.12 fully binary compatible with the latest libexif? I mean: if a program is compiled against libexif 0.5.12, and I rename libexif 0.6's library name to the name used by libexif 0.5.12, will that program still work? And when was version 0.5.12 released? |
From: Lutz <lu...@us...> - 2005-04-15 19:50:12
|
On Fri, 2005-04-15 at 21:13 +0200, Hongli Lai wrote: > Ok, so the problem is that you don't understand libtool versioning=20 > correctly. You should read 'info libtool' -> section Versioning. I guess reading the small documentation in libexif/configure.in should be sufficient for the average developer especially now that you have corrected it: > I attached a one-liner patch which fixes the=20 > comments. Applied. Thanks! > Is libexif 0.5.12 fully binary compatible with the latest libexif? I=20 > mean: if a program is compiled against libexif 0.5.12, and I rename=20 > libexif 0.6's library name to the name used by libexif 0.5.12, will tha= t=20 > program still work? No. I quickly read through libexif/ChangeLog and now remember 1 change that we did between 5.11 (2003/08) and 6.9 (2004/05):=20 2004-01-07 Jan Patera <pa...@us...> Thread-safety, elimination of static variables, fixes of memory corruption (writing beyond provided space), no more memory leaks in mnote, 2 new args of exif_entry_get_value, That is, a new required parameter has been added to the function exif_entry_get_value. But that should be the only change since 5.12. Please forgive me my ignorance, but I never even think about manually linking programs or replacing old libraries with new ones manually. "./autogen.sh && make install" usually does everything for me (including checks for compatibility). Regards --=20 Lutz M=FCller <lu...@us...> |