Date: Fri, 20 Feb 2009 20:23:43 +0100 From: "Thomas Schmitt" <scdbackup@gmx.net> To: freebsd-ports@freebsd.org Subject: Problem with .so numbering on FreeBSD in contrast to Linux Message-ID: <1027221507572@212.46.126.165>
next in thread | raw e-mail | index | archive | help
Hi, i am trying to provide libraries for FreeBSD and Linux via a build system based on autotools. My problem is that the .so numbers get produced differently on both systems. E.g. libburn.so.31 on FreeBSD libburn.so.4.27.0 on Linux This has the consequence that on Linux older applications can work with the newest libraries whereas on FreeBSD the application has to be re-built for that. Is that intentional on FreeBSD ? Shall there be no backward compatibility with .so ? The numbers stem from ./configure.ac LT_CURRENT=31 LT_AGE=27 LT_REVISION=0 They are handed over to ./libtool as -version-info 31:0:27 on both systems. The libburnia libraries have evolving ABIs which are backward compatible. Applications can inquire the library version at run time in order to check whether the feature set suffices. So i would prefer to produce libburn.so.4 with every new release. But i also want to obey the conventions of the operating systems. On Linux that means to increase both LT_CURRENT and LT_AGE. On FreeBSD one would obviously have to leave LT_CURRENT unchanged. How do other projects solve that dilemma ? Should i strive for constant libburn.so.4 on FreeBSD at all ? (libtool is the expert. Possibly it is smarter than me.) Have a nice day :) Thomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1027221507572>