Date: Sun, 22 Feb 2009 12:32:12 -0600 From: "Jeremy Messenger" <mezz7@cox.net> To: "Thomas Schmitt" <scdbackup@gmx.net> Cc: freebsd-ports@freebsd.org Subject: Re: Problem with .so numbering on FreeBSD in contrast to Linux Message-ID: <op.uprm4mam9aq2h7@localhost> In-Reply-To: <102368789721915@212.46.126.165> References: <20090222093452.31721928ruovf3gk@webmail.leidinger.net> <102368789721915@212.46.126.165>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Feb 2009 03:16:21 -0600, Thomas Schmitt <scdbackup@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.uprm4mam9aq2h7>