Re: Linking problem with FreeBSD

[Owen Taylor <otaylor gtk org>]

Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> writes:

> Sorry if the reply format is kind of lame, but my mailer died on this
> particular mail... I'll spare the gory details. It involved /tmp filling up.
> 
> On 07-Feb-99 Owen Taylor wrote:
> > Marc van Kempen <marc@bowtie.nl> writes:
> 
> > net/openbsd:
> >   library_name = libgtk-1.1.so.14.1
> >   symlinks = NONE
> >
> > sunos
> >   library_name = libgtk-1.1.so.14.1
> >   symlinks = libgtk.so.14.1
> >
> > freebsd-elf:
> >   library_name = libgtk-1.1.so.14.1
> >   symlinks = libgtk.so
> 
> Hey, wait a second. If the library getting created ends with .so.14.1 then
> it won't work under FreeBSD's with ELF. The library naming must adhere to
> the .so.n scheme. I hope that was a typo Owen?

That was a typo. That was meant to be freebsd-aout.

freebsd-elf looks like it will be libgtk-1.1.so.14

(It is a little odd to me that FreeBSD, instead of
going with the standard system of naming the library
with the version number and symlinking to it, just
names all the libraries for the same major the same,
but I suppose it makes sense, in that it never
profits to have two libraries with the same soname
installed)
 
> > So it basically looks, to me, not having any of these
> > platforms to test:
> >
> > On freebsd-aout, our current scheme doesn't work 
> > an incorrect symlink is created that confuses things.
> >
> > So, I think, it might sort of work, to say
> >
> > "if the version_type is sunos, or freebsd-aout, and no
> >  soname_spec is set, then put -lgtk-1.1 into gtk-config."
> >
> > I can implement that, and have some confidence that it
> > will at least improve things a bit, but I have the
> > strong feelings:
> > 
> > a) I don't really understand the situation
> > b) libtool has some problems with it's handling of $release
> > 
> > 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. When I asked one of the of the FreeBSD-ports people 
> > who was working on GLib about this, they sort of shrugged
> > and said: "we basically ignore the shared library versioning
> > that the package does and make up our own." Which
> > didn't exactly increase my confidence level.
> 
> Whom ye spoke with btw? With most ports we simply use the library names and
> versions as they come with the package. IMHO the current ports with
> gtk/glib are patched up too much without the patches being backfeeded to
> the efforts for review.

Well, that was the impression I got from email exchanged
with Jeremy Lea (who was working at that time on the GLib port).
But I may have misunderstood what he was saying.
 
I don't think the problem per-se is that the patches aren't
beeing backfeeded. Most of the stuff in the FreeBSD port
has been sent to us at one time or the other. The problem
seems to be more that a lot of the patches are FreeBSD
specific instead of being suitable for inclusion in the
mainline sources.

> > Anybody who made it through the above, probably understands
> > why I've sort of given up, and am waiting for somebody
> > who understands, and has access to, *BSD boxes, to send
> > in patch to fix things.
> 
> I have access to BSD boxen, FreeBSD in particular and probably able to test
> on OpenBSD and NetBSD as well.

Help getting this working is much appreciated.
 
> >> 2. Add an extra symbolic link
> >> 
> >>         Currently these links are being made:
> >> 
> >>         libgdk-1.1.so.14.1                                               
> >   
> >          libgdk.a
> >>         libgdk.la
> >>         libgdk.so -> libgdk-1.1.so.14.1
> >> 
> >>         Adding this link solves the problem:
> >> 
> >>         libgdk.so.14.1 -> libgdk-1.1.so.14.1
> >
> >This is an incorrect link, because it defeats our
> >naming scheme. Once we have a 1.3 development
> >branch, we might eventually have a libgdk-1.3.so.14.1,
> >which will be incompatible with libgdk-1.1.so.14.1.
> 
> All of the above will not work with ELF.
> 
> That needs a library named libgdk-1.1.so.14 
 
It is created currently, I believe.

> Besides aout libraries can also use libgdk-1.1.so.14.1 as name. So I don't
> see where the problem is coming from.

The problem is that we currently put -lgtk in the 
link line (and would like to continue doing this). 
On a standard ELF system, we have a symlinks from

 libgtk.so => libgtk-1.1.so.14.0.1
 libgtk-1.1.so => libgtk-1.1.so.14.0.1

and we write a soname of "libgtk-1.1.so" into
the library.

On aout systems, this doesn't work at all, since
the linker (I think) actually records the library
filename it found at linktime and uses that 
at runtime.

It looks to me that it won't work on free-bsd
ELF either, since no soname is specified when
building the library.

                                        Owen