Re: Libtool versioning made easy (was Re: Converting libraries andplugins to use gtk3

[dmacks netspace org]

On Wed, 30 Jun 2010 16:33:28 -0400, Behdad Esfahbod  wrote:
 On 06/30/2010 04:26 PM, Adam Jackson wrote:
 > > On Wed, 2010-06-30 at 15:43 -0400, Behdad Esfahbod wrote:
 > >
 > >> In your src/Makefile.am add "-version-info   $(LT_VERSION_INFO)" to your
 > >> library's LDFLAGS.
 > >
 > > Or you could just do it directly:
 > >
 > > libX11_la_LDFLAGS = -version-number 6:3:0 -no-undefined
 > >
 > > gives you libX11.so.6.3.0.
 >
 > Using straight major.minor.micro is actually a good idea too.
 Maybe we should
 > do that.  The only difference with my scheme is that my scheme
 assumes that
 > individual releases in a devel series all add new interfaces   whereas using
 > major.minor.micro directly assumes that no point releases adds  new
 interfaces
 > (stable or not).  Both assumptions are wrong, but mine is on the
 safe side.
 > The only reason I like your proposal is that I don't think anyone
 makes any
 > assumption about minor .so version anyway...
  
 Some platforms' (hi darwin!) library format has an internal interface
 versioning counter. That's why libtool is so weird: -version-info
 speaks  specifically and only to the *interface* versioning, because it
 knows  how to set those flags. In particular, it knows when to change
 SONAME  and when just to increase a version counter. That's a great
 feature! It  keeps updates from accidentally breaking things. And the
 dynamic linker  even knows to check the current version vs the one used
 when compiling  and give a plain-language error message about version
 too old--kinda  like symbol-versioning.
  
 I really don't care what additional atoms gets appended to the
 filename, but ELF naming conventions do a poor job of delineating what
 the SONAME is. And lots of libraries break ABI in minor releases. That
 is, going from version 6.3.0 to 6.4.0 of libX11 *must* change SONAME,
 not remain libX11.so.6 because it is not drop-in compatible with the
 previous one.
  
 > > libtool very sensibly only really documents -version-info   because, in
 > > this one instance, they chose to implement something so   utterly
 > > orthogonal to any library versioning scheme ever seen in the   wild as to
 > > be unusable, instead of their usual strategy of implementing   something
 > > so lowest-common-denominator as to be unusable.
  
 The instructions give a clear flowchart about what sorts of library
 changes should result in what changes to the -version-info flag. It's
 pretty different from other tools' versioning flags because it can
 handle linkers with features linux's doesn't have that are cool and
 useful on those platforms. It seems like the kernel of this proposal is
 to not bother having read the docs and to subvert even the most basic
 interface versioning/stability goals just to get a pretty filename.
 dan
  
 --
 Daniel Macks
 dmacks netspace org