Date: Tue, 9 Feb 1999 09:50:03 +0200 From: Jeremy Lea <reg@shale.csir.co.za> To: Kris Kennaway <kkennawa@physics.adelaide.edu.au> Cc: Marc van Kempen <marc@bowtie.nl>, ports@FreeBSD.ORG Subject: Re: Shared library problem Message-ID: <19990209095003.K96974@shale.csir.co.za> In-Reply-To: <Pine.OSF.4.05.9902091442570.13062-100000@mercury.physics.adelaide.edu.au>; from Kris Kennaway on Tue, Feb 09, 1999 at 02:54:38PM %2B1030 References: <199902082018.VAA15439@bowtie.nl> <Pine.OSF.4.05.9902091442570.13062-100000@mercury.physics.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Tue, Feb 09, 1999 at 02:54:38PM +1030, Kris Kennaway wrote:
> On Mon, 8 Feb 1999, Marc van Kempen wrote:
>
> > I'm having a discussion on the gtk development list about the linking
> > scheme that is imposed when configuring for FreeBSD 2.2.x.
Probably the wrong place to have such a discussion. The linking scheme is
that imposed by libtool.
> > At the moment symlinks as follows are created when installing the beast
> > (gtk+-1.1.15 and glib-1.1.15)
> >
> > libgtk-1.1.so.14.1
> > libgtk.a
> > libgtk.la
> > libgtk.so -> libgtk-1.1.so.14.1
> >
> > If I leave out the link below:
> >
> > libgtk.so.14.1 -> libgtk-1.1.so.14.1
> >
> > Things go wrong when trying to link, since gtk-config (a shell script to
> > return library flags and compiler flags) returns -lgtk, and thus the
> > aout linker tries to link with libgtk.a
> >
> > My proposed solution (adding the link) was rejected because that would get
> > in the way of versioning, since after the gtk-1.2 is released they will
> > continue with gtk-1.3 and multiple libraries must be able to coexist.
> >
> > To cut a long story short, another solution is to have 'gtk-config' specify
> > -lgtk-1.1 as the library to link with, however is the following reason
> > valid to determine this case:
> >
> > "if the version_type is sunos, or freebsd-aout, and no
> > soname_spec is set, then put -lgtk-1.1 into gtk-config."
> >
> > Or to put it more simply, when freebsd-aout is found is it safe to
> > assume that -lgtk-1.1 is necessary?
The other problem is that the GLIB/GTK+/GNOME people using multiple
versions wouldn't know a proper compatible installation if it came up
and bit them. Their idea of a multiple version install is one that
allows them to link only against the latest installed version.
Your solution of using the link is only half right, since you want to
use the minor version number as the major number of the library, and the
release number as the minor number (ie libgtk.so.1.14). This will
still break multiple version installs at run time since they don't bump
the minor version number when there is breakage in the API, but would
solve the 1.0, 1.1, 1.2, 1.3 issue.
I sent a long e-mail to Owen Taylor explaining the mechanisms which
FreeBSD uses to link shared libraries on aout and ELF and got no
response. I also sent him patches for Glib to get proper flags for
linking with libpthread and libc_r, and to get their tests working, but
not a commit (although three different people all tried various broken
methods of adding threading support for FreeBSD). The solution in the
ports collection is still not the best, since their configure file can't
handle a pltform with two threading libraries (as FreeBSD 3.x and 4.x
can have).
Basically the aout linker will only link with lib<name>.so.M.N and the
ELF linker will only link with lib<name>.so. At run time the aout
linker will try to find lib<name>.so.M.X, where X has the highest
number, and the ELF linker will try to match the -soname given to the
library when it was built (should be lib<name>.so.M).
The correct solution to this problem is to use the FreeBSD ports
collection, since it's unlikely that the braindamage that is libtool
will ever get fixed.
> For ports which aren't quite so smart, you may have to manually exit
> the reference to gtk-config to point to the correct copy. It's still
> quite easy to do..I don't know that it's something which the GTK folks
> need to change about their build process (except, possibly, to stop
> breaking backwards compatability with the API). On the other hand,
> perhaps we should consider naming our libraries libgtk-1.1{d}.so.*
> instead of libgtk11d.so.* to bring ourselves more into line with what
> the rest of the GTK world uses.
That would not solve the problem. The ports have to install their
headers into seperate directories (.../include/{gtk10|gtk11|gtk11d} at
the moment), and all the libraries have to be renamed (which can't be
done with libtool):
libgtk-1.1.so.14.1 > libgtk11d.so.1.0
libgtk.a > libgtk11d.a
libgtk.la > libgtk11d.la
libgtk.so > libgtk11d.so
The ports do this by heavy patching to get around the use of explict
library base names in libtool's targets, and use their own numbering
convention, which should bump the major number every time the API
changes. I think using '-1.1d' instead of '11d' might break the
makefiles. '11d' is more in line with FreeBSD's style, but maybe '-11d'
is a better compromise.
Kris, since no one has responded to your libtool e-mail: I think it is
a very good one, especially if the libtool in /usr/local was patched to
be able to add version number suffixes to library names without the need
to do heavy patching of the port's makefiles. i.e. You could call
libtool mode=link -version-info 1:0:0 -release 11d and get the libraries
listed above. This would take most of the work out of upgrading libtool
based ports like Glib and GTK+.
Regards,
-Jeremy
--
| "Come home my prodigal son, come home and lets be one,
--+-- don't want to see you cry, don't make me tell you why,
| you've lived in a house with me, my blood has set you free,
| in the world you'll surely die, nothing else will satisfy." -MIC
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?19990209095003.K96974>