Date: Sun, 22 Feb 2009 10:16:21 +0100 From: "Thomas Schmitt" <scdbackup@gmx.net> To: freebsd-ports@freebsd.org Subject: Re: Problem with .so numbering on FreeBSD in contrast to Linux Message-ID: <102368789721915@212.46.126.165> In-Reply-To: <20090222093452.31721928ruovf3gk@webmail.leidinger.net> References: <20090222093452.31721928ruovf3gk@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?102368789721915>