Re: -lgdk -vs- -lgdk-1.1

[Owen Taylor <otaylor gtk org>]

Gary V Vaughan <gvaughan@oranda.demon.co.uk> writes:

> [1  <text/plain; us-ascii (quoted-printable)>]
> On Mon, May 11, 1998 at 08:42:21AM -0700, Matt Stockdale wrote:
> > It seems that recently we changed over to gtk-1.1 gdk-1.1 and glib-1.1.
> > 
> > However, when I get gtk+ fresh from cvs, it still installs on my system as
> > libgtk. no -1.1. However, the gtk-config that gets installed spits out -1.1. So
> > I either have to edit gtk-config, or link the libs it installs. the only
> > reference I could find to -1.1 in the tree was in the .spec file.
> > 
> > Can someone shed some light on this for me?
> 
> As I understand it (from the ChangeLog), the ltmain.sh and/or ltconfig
> scripts from CVS are generated by a hacked libtool-1.2.  Using these files
> will postfix the version number to the library names as they are installed.
> 
> Rerunning libtoolize (as my version of autogen.sh does) overwrites these
> changed files with the normal configuration scripts which install without
> the version postfix.

The standard autogen.sh distributed with GTK+ does not rerun 
libtoolize. For a number of reasons:

 - It is not necessary. Unlike automake, or autoconf, the output
   does not depend on other files in the distribution that might
   be modified.

 - We'd rather not have to track down bugs in libtool, so we, 
   if possible, stick with stable releases.

So unless Matt is also running a modified autogen.sh, I don't think
this is his problem. It might be more likely that autogen.sh wasn't
run at all, or for some other reason libtool wasn't regenerated.
 
(Although some -1.1 dependencies may have slipped into GNOME, the -1.1
branch of GTK+ is meant at this stage primarily for people interested
in the development of GTK+ itself. For general usage, the gtk-1-0
branch is recommended.)

> Aside:
> I think that version numbers in library names are a bad idea for ELF systems
> at least.  The soname option to ld should be used correctly to differentiate
> versions of libraries.  A good scheme is documented in the info files 
> distributed with libtool... I am hoping that this is just an interim measure
> to get us through the gtk-1.0 to gtk-1.1 transition (albeit a misconceived
> one IMHO)... If the source version number as library name thing is here to
> stay perhaps someone could explain why this is necessary?

The above paragraph gives the perhaps somewhat misleading impression
that libtool does something unusual with the -soname option.

In fact, libtool's merely uses -soname (on ELF platforms) to emulate a
versioning system where a binary linked with libfoo.so.x.y.z can
be used with libfoo.so.x'.y'.z' if x = x', and y' >= y.

Then it uses that system in a somewhat more complicated manner. Now,
there is nothing horribly wrong with libtools versioning scheme,
in fact:

 The current versioning scheme is exactly libtool's versioning
 scheme, except that we add -$(MAJOR)-$(MINOR) to the library
 names and start over for each major.minor pair.

The unmodified libtool scheme has the disavantage that gtk+-1.1
would immediately have version number libgtk.so.2.0.0, and
if we properly mantained versioning in the development branch,
gtk+-1.2 would end up with a version number libgtk.so.10.0.0,
or so. (gtk+-2.0, probably libgtk.so.25.0.0)

Many people would say that there is nothing wrong with
such version numbers. It is it however, quite noticeable,
that version numbers that don't look anything like the
package version numbers cause considerable confusion.

So, our hope was that a version name:

 libgtk-1.2.so.0.0.0

Would make it clear that it is part of the GTK+-1.2.0 package,
while retaining the ability to convey the necessary versioning
information in the shared library version numbers (0.0.0)

It is a somewhat experimental system, so I'm not sure that
we'll keep it beyond the -1.1 branch. But the above is the
principle reason for the change.

Regards,
                                        Owen