Problem with .so numbering on FreeBSD in contrast to Linux
Thomas Schmitt
scdbackup at gmx.net
Fri Feb 20 11:50:06 PST 2009
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
More information about the freebsd-ports
mailing list