Date: Sat, 20 Feb 1999 18:12:37 +0200 From: Jeremy Lea <reg@shale.csir.co.za> To: Marc van Kempen <marc@bowtie.nl> Cc: Kris Kennaway <kkennawa@physics.adelaide.edu.au>, ports@FreeBSD.ORG, sada@FreeBSD.ORG Subject: Re: Shared library problem Message-ID: <19990220181237.B79671@shale.csir.co.za> In-Reply-To: <199902091121.MAA23292@bowtie.nl>; from Marc van Kempen on Tue, Feb 09, 1999 at 12:21:00PM %2B0100 References: <19990209095003.K96974@shale.csir.co.za> <199902091121.MAA23292@bowtie.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
I finally got a chance to look at this in a bit more detail...
On Tue, Feb 09, 1999 at 12:21:00PM +0100, Marc van Kempen wrote:
> In my view they are actually trying to stuff in another version decimal
> in there.
It's worse than that... They really don't understand that product
version numbers and API versions are totally different things. Look at
this snippet from glib/configure.in:
---------
# The following version number definitions apply to GLib and GModule
# as a whole, so if changes occoured in either of them, they are both
# treated with the same interface and binary age.
#
# Making releases:
# GLIB_MICRO_VERSION += 1;
# GLIB_INTERFACE_AGE += 1;
# GLIB_BINARY_AGE += 1;
# if any functions have been added, set GLIB_INTERFACE_AGE to 0.
# if backwards compatibility has been broken,
# set GLIB_BINARY_AGE and GLIB_INTERFACE_AGE to 0.
#
GLIB_MAJOR_VERSION=1
GLIB_MINOR_VERSION=1
GLIB_MICRO_VERSION=16
GLIB_INTERFACE_AGE=0
GLIB_BINARY_AGE=0
GLIB_VERSION=$GLIB_MAJOR_VERSION.$GLIB_MINOR_VERSION.$GLIB_MICRO_VERSION
dnl
AC_DIVERT_POP()dnl
AC_SUBST(GLIB_VERSION)
# libtool versioning
LT_RELEASE=$GLIB_MAJOR_VERSION.$GLIB_MINOR_VERSION
LT_CURRENT=`expr $GLIB_MICRO_VERSION - $GLIB_INTERFACE_AGE`
LT_REVISION=$GLIB_INTERFACE_AGE
LT_AGE=`expr $GLIB_BINARY_AGE - $GLIB_INTERFACE_AGE`
---------
These are then used like this:
-version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
-release $(LT_RELEASE)
to get a library named (depending on the scheme):
libglib-$(LT_RELEASE).so.$(LT_CURRENT).$(LT_REVISION).$(LT_AGE)
As you can see, the numbers they end up with are sort of an API version
number per minor number release (with real minor and major numbers of
the API reversed and the real major number ignored on most platforms)...
They should just have:
# if any functions have been added: GLIB_BINARY_AGE += 1.
# if backwards compatibility has been broken:
# GLIB_BINARY_AGE = 0, GLIB_INTERFACE_AGE += 1.
GLIB_INTERFACE_AGE=0
GLIB_BINARY_AGE=0
LT_RELEASE=$GLIB_MAJOR_VERSION.$GLIB_MINOR_VERSION
LT_CURRENT=$GLIB_INTERFACE_AGE
LT_REVISION=$GLIB_BINARY_AGE
LT_AGE=0
And then they would not need the $(LT_RELEASE) in the library name in
most cases. Although by now it would be libglib.so.24.0 or so, since
they don't make any effort not too break backwards compatibility.
> Please try to remind him, I got the impression from his answer on the
> gtk-list that he is actually willing to commit changes in order to support
> FreeBSD, but at the moment is not very clear about what has to be done.
I don't know if there is really much use to try and support FreeBSD
properly, since it will put a nice spanner in the Linux works...
> "if the version_type is sunos, or freebsd-aout, and no
> soname_spec is set, then put -lgtk-1.1 into gtk-config."
No. Just drop the ${release} and forget the (broken) multiple version
support for CVS builds. If you need old versions on FreeBSD, then the
ports collection provides them. This will also mean less patching in
the ports collection... The ltconfig line should look like this for
FreeBSD:
library_names_spec='${libname}.so${versuffix} ${libname}.so'
I'll send another e-mail to him explaining this in more detail...
> On freebsd-elf I have no idea how anything is working at all, if
> it is, from reading the sources. FreeBSD-elf presumably has the
> ability to set the soname, but libtool doesn't seem to be doing
> so.
This baffled me for a bit, until I really started tracing things through
libtool... And to my surprise, I found that the compiler/linker block
for FreeBSD-elf was being totally ignored. Since we are now using GNU
ELF tools, its picking up the generic rules for them.
I owe sada an apology, because I flamed him for not patching this block
for 4.0, and it turns out it wasn't needed (except for aout support I
think...). We should add a patch to libtool to remove this block
entirely, since aout should not be supported on FreeBSD 3 and 4, and
it's just going to confuse people.
Regards,
-Jeremy
--
| "I could be anything I wanted to, but one things true
--+-- Never gonna be as big as Jesus, never gonna hold the world in my hand
| Never gonna be as big as Jesus, never gonna build a promised land
| But that's, that's all right, OK with me..." -Audio Adrenaline
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990220181237.B79671>