Problem with .so numbering on FreeBSD in contrast to Linux

Thomas Schmitt scdbackup at gmx.net
Sun Feb 22 01:16:04 PST 2009


Hi,

Alexander Leidinger wrote:
> > which i believe complies to policies-shlib.html.
> I think this is a little bit outdated. We only have one number after the .so
> since a long time. All libs in /lib and /usr/lib are .so.X and for 3rd party
> applications most are .so.X (those which aren't are a sign of bugs in the
> ports collection).

So this is really a feature. Ahum.

What is the meaning of that single number ?
Shall it be incremented with each new release
or shall it be kept stable until ABI backward
compatibility gets broken ?

I.e. shall i produce
  libburn.so.4
with each release,
or shall i produce
  libburn.so.27
  libburn.so.29
  libburn.so.31
where Linux would have 4.23.0, 4.25.0, 4.27.0
and let .so.4 applications start with any of those.

A compatibility check at run time is part
of the libburn API specs. So the applications
are supposed to be able to detect feature sets
that are too old for their needs.
I.e.  libburn.so.4  would be technically ok.

My question is about the FreeBSD conventions
in order to be friendly to my port maintainer
and to sysadmins.


Myself wrote:
> > Maybe the FreeBSD community should discuss this
> > with the GNU libtool project.
Alexander Leidinger wrote:
> On one of my systems 1.2% are not .so.X:

Well, it looks like rather the online handbook needs
to be discussed first. 

For now i have to ask the bystanders here
for their opinions.


Have a nice day :)

Thomas



More information about the freebsd-ports mailing list