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
 [email protected]
  

_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to