From owner-freebsd-ports Mon Feb 8 23:52:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA20220 for freebsd-ports-outgoing; Mon, 8 Feb 1999 23:52:17 -0800 (PST) (envelope-from owner-freebsd-ports@FreeBSD.ORG) Received: from shale.csir.co.za (shale.csir.co.za [146.64.46.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA20211 for ; Mon, 8 Feb 1999 23:52:11 -0800 (PST) (envelope-from reg@shale.csir.co.za) Received: (from reg@localhost) by shale.csir.co.za (8.9.2/8.9.2) id JAA91966; Tue, 9 Feb 1999 09:50:03 +0200 (SAT) (envelope-from reg) Date: Tue, 9 Feb 1999 09:50:03 +0200 From: Jeremy Lea To: Kris Kennaway Cc: Marc van Kempen , ports@FreeBSD.ORG Subject: Re: Shared library problem Message-ID: <19990209095003.K96974@shale.csir.co.za> References: <199902082018.VAA15439@bowtie.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Kris Kennaway on Tue, Feb 09, 1999 at 02:54:38PM +1030 Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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.so.M.N and the ELF linker will only link with lib.so. At run time the aout linker will try to find lib.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.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