On Sun, 22 Feb 2009 03:16:21 -0600, Thomas Schmitt <scdbac...@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-unsubscr...@freebsd.org"
--
me...@cox.net - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.org
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
