RE: [gtk-list] Re: Linking problem with FreeBSD

[Jeroen Ruigrok/Asmodai <asmodai wxs nl>]

On 07-Feb-99 Owen Taylor wrote:

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

>> On 07-Feb-99 Owen Taylor wrote:
>> 
>> > 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.

Phew =)

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

Correct, 't is.

> (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)

*nods* I have raised this question myself last week, hence I am jumping in
on it and that was exactly the idea as provided to me by John Polstra.
Libraries are supposed to be backwards compatible under a given major. As
soon as the major gets bumped then it's a totally different ballgame.

>> > 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.

Aye, we have the ability to set the soname, and the currect patches in our
ports tree do so if I'm not mistaken.

>> 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.

Ahh, well the current maintainer is Vanilla Shu.

> 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.

Where it concerns hacking makefiles to use variables set for use with the
ports system, yes, the rest might not be so specific. I'll look over them
again.

>> > 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.

Please note that the FreeBSD system I have easy access on (my own box) is
ELF. And apart from changing ltconfig to create shared libraries for 4.0 it
worked like a charm. Except gettext, but I'm looking into that.

[ snip link/library names ]

>> 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.

*nods* Correct.

>> 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.

The linker currently in use on FreeBSD CURRENT (4.0) is:

GNU ld 2.9.1

My guess is that this is the same version for 2.2.x and 3.x

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

Funny then, here have a peek:

480 -rwxr-xr-x  1 root  wheel  -  476816 Feb  4 22:05 libglib-1.1.so.13*
720 -rw-r--r--  1 root  wheel  -  726476 Feb  4 22:05 libglib.a
  1 -rwxr-xr-x  1 root  wheel  -     517 Feb  4 22:05 libglib.la*
  0 lrwxr-xr-x  1 root  wheel  -      17 Feb  4 22:05 libglib.so@ ->
libglib-1.1.so.13

4696 -rwxr-xr-x  1 root  wheel  - 4797220 Feb  5 07:06 libgtk-1.1.so.14*
8856 -rw-r--r--  1 root  wheel  - 9052296 Feb  5 07:06 libgtk.a
   1 -rwxr-xr-x  1 root  wheel  -     587 Feb  5 07:06 libgtk.la*
   0 lrwxr-xr-x  1 root  wheel  -      16 Feb  5 07:06 libgtk.so@ ->
libgtk-1.1.so.14

Looks fine to me. Unless ye are referring to libgtk.so not being
libgtk-1.1.so?

If ye have anything for me to test, feel free to call upon me. I am
currently looking into libtool (subscribed to the list as well as automake
and autoconf) so expect me to take this up as far as my knowledge and
ability go (then again, expect me to extend my knowledge because I want to
know the how and why anyway =).

---
Jeroen Ruigrok van der Werven        join #FreeBSD on Undernet
asmodai(at)wxs.nl       Time is merely a residue of Reality...
Network/Security Specialist      <http://home.wxs.nl/~asmodai>
*BSD: Powered by Knowledge & Know-how <http://www.freebsd.org>