Re: MirBSD support and a question

[Benny Siegert]

On Thu, 3 Feb 2011, Ralf Wildenhues wrote:

> * Benny Siegert wrote on Sat, Jan 29, 2011 at 04:50:04PM CET:
> > I would like to add MirBSD support to upstream libtool. MirBSD (or
> > MirOS BSD) is an OS derived from OpenBSD. I want to use
> > version_type=linux instead of sunos because it works much better,
> > from several years experience with our own patched version of
> > libtool 1.5.
>
> Do I understand correctly that your patched libtool used in MirBSD also
> uses version_type=linux?

Yes, this is correct.

> Are there users out there who use some libtool on MirBSD that uses a
> different version_type?  This is very important to know, as when we add
> support, for they might need a flag day when their old libraries and
> programs start breaking.

I do not think so. The patched libtool has existed for more than five 
years now.

> > A notable idiosyncrasy of our runtime linker is that shared
> > libraries _must_ have a two-digit version (libfoo.so.0.0 for
> > example) to be able to link against them. In the attached patch, I
> > solved it like this:
> >
> > library_names_spec='${libname}${release}${shared_ext}${major}.${age}
> > ${libname}${shared_ext}${major}.${age}'
> >
> > Is this okay or should it be done differently?
>
> Well, that's really hard to answer without knowing the exact semantics of
> your link editor and runtime linker.  What gets encoded as DT_SONAME,
> and as DT_NEEDED?  How are symlinks set usually, if any?  Does the
> runtime linker consider libraries with some sets of numbers as
> compatible upgrades (like GNU ld.so does), and if so, how is the
> encoding of the numbers?  Which numbers are allowed where (zero or only
> greater ones)?

1. Shared libraries must have either a zero-component version (i.e. 
libfoo.so) or a two-component version (libfoo.1.2). The former is 
equivalent to having 0.0 as the version. 0.0 is the lowest allowed 
version.

2. Libraries with different major versions are incompatible. Libraries 
with the same major but a newer minor version are considered 
binary-compatible (i.e. 4.2 is compatible with 4.0 and 4.1, but not with 
3.0). Thus, we use version_type=linux, where major=current-age and 
minor=age. revision is ignored.

3. There are no symlinks.

4. Linking against a library with only the major number (i.e. with a file 
name of libfoo.so.1) fails. This is probably a bug in our linker (which, 
by the way, is a patched GNU ld). However, bundles -- which are only 
dlopened, not linked against -- can have arbitrary filenames.

5. The filename of the library, or the DT_SONAME if non-null, is encoded 
in the DT_NEEDED field. DT_RPATH works as under Linux. The SONAME can be 
given with -Wl,-soname,$name.

Here is a short example:

address@hidden:~ $ ls
foo.c  main.c
address@hidden:~/library-test $ gcc -c foo.c
foo.c:0: note: someone does not honour COPTS correctly, passed 0 times
address@hidden:~/library-test $ mgcc -shared -o libfoo.so foo.o
address@hidden:~/library-test $ ls
foo.c     foo.o     libfoo.so main.c
address@hidden:~/library-test $ mgcc -o main -L. -lfoo main.c
main.c:0: note: someone does not honour COPTS correctly, passed 0 times
address@hidden:~/library-test $ ls
foo.c     foo.o     libfoo.so main      main.c
address@hidden:~/library-test $ mv libfoo.so libfoo.so.1.0
address@hidden:~/library-test $ mgcc -o main -L. -lfoo main.c
main.c:0: note: someone does not honour COPTS correctly, passed 0 times
address@hidden:~/library-test $ objdump -p main | grep NEEDED
  NEEDED      libfoo.so.1.0
  NEEDED      libc.so.41.9
address@hidden:~/library-test $ mv libfoo.so.1.0 libfoo.so.1
address@hidden:~/library-test $ mgcc -o main -L. -lfoo main.c
main.c:0: note: someone does not honour COPTS correctly, passed 0 times
/usr/bin/ld: cannot find -lfoo
collect2: ld returned 1 exit status

> > However, there is one case where this breaks: When a -release is
> > given but no -version-info, the $major variable is reset. In
> > ltmain.m4sh, line 6705, $major is reset to an empty string:
> >
> >         # Clear the version info if we defaulted, and they specified
> > a release.
> >         if test -z "$vinfo" && test -n "$release"; then
> >           major=
> >
> > Why is this so? Can this line be safely removed?
>
> I don't think it can.  Don't you just need to set need_version=yes?
> See the dozen or so lines below this.

Or we could avoid the version entirely, lib$name-$release.so works.

> Other than the points above, your patch looks ok to me.  It still needs
> a proper ChangeLog entry and a NEWS entry, but we can write that.  Do
> you mind being added to THANKS?

No, I don't mind, thanks! I will try to write a proper ChangeLog entry.

--Benny.

PS: Thank you for the helpful answer and for the nice chat at FOSDEM ;)