On Mon, 4 Jun 2012, Jeremy Huddleston wrote: > On Jun 4, 2012, at 1:34 PM, Julien Cristau <jcris...@debian.org> wrote: > > > On Sat, Jun 2, 2012 at 16:41:02 -0700, Jeremy Huddleston wrote: > > > >> Why did "Do not rely anymore on gperf and m4 following removal of > >> deprecated atoms." do this: > >> > >> -libxcb_util_la_LDFLAGS = -version-info 0:0:0 -no-undefined > >> +libxcb_util_la_LDFLAGS = -version-info 1:0:0 -no-undefined > >> > >> I don't see this change requiring a major version bump which should > >> only be done for binary compatibility changes. Yes, you removed the > >> xcb_atom_get_predefined and xcb_atom_get_name_predefined functions, > >> but not in a binary incompatible way, so you should not have bumped > >> the major version which requires relinking every library and > >> application that links against the library. > >> > > How are the xcb_atom_get_predefined/xcb_atom_get_name_predefined > > removals not binary incompatible?? > > Nothing else changed, just the removal of the symbols. All other > functions did not change their signatures. > > Think about this from the libc perspective. libc *may have* strlcat > or not, but they're named the same because all functions in libc have > consistent signatures.
>From a libtool point-of-view, -version-info change looks correct for interface removal: "current" is incremented and revision and age are set to 0. _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
