Problem with .so numbering on FreeBSD in contrast to Linux

[Jeremy Messenger]

On Sun, 22 Feb 2009 03:16:21 -0600, Thomas Schmitt <scdbackup at gmx.net>  
wrote:

> 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 ?

Correct, when the ABI changes then bump +1 number. It does not make any  
sense to force anyone to rebuild all applications to get relink when there  
is no ABI breaks.

> 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.

The API can be check version inside the *.pc file by via configure. Like  
if the configure checks 'pkg-config --modversion foo-1' and if it's lower  
than what configure wants then output an error for need to update libfoo.  
It's what all other applications do like GTK+2, pango, cario and etc. For  
example, in gedit's configure.ac has:

---------------------------------------------
PKG_CHECK_MODULES(GEDIT, [
	sm >= 1.0.0
	libxml-2.0 >= 2.5.0
	glib-2.0 >= 2.13.0
	gthread-2.0 >= 2.13.0
	gio-2.0 >= 2.16.0
	gtk+-2.0 >= 2.13.0
	gtksourceview-2.0 >= 2.2.0
	gconf-2.0 >= 1.1.11
])
---------------------------------------------

Or/and use the header (*.h) to check API stuff. I don't do C programming  
very well, so.. dunno.

> 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.

You can keep patch in tarball if you want to. But you don't really need to  
do that and you can tell your port mainainer to add ltverhack in libburn  
port. Unitl libtool has the fix then none of that will be need.

As for the libtool2 that still doesn't has fix. Yes, I guess, someone will  
have to report to libtool2. I think the libtool developers knew, but don't  
know why no action take.

Cheers,
Mezz


> 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
>
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"



-- 
mezz7 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org