Re: -lgdk -vs- -lgdk-1.1 [LONG]

[Gary V Vaughan <gvaughan oranda demon co uk>]

Earlier, I <Gary> wrote:
Gary> As I understand it (from the ChangeLog), the ltmain.sh and/or
Gary> ltconfig scripts from CVS are generated by a hacked libtool-1.2.
Gary> Using these files will postfix the version number to the library
Gary> names as they are installed.
Gary>
Gary> Rerunning libtoolize (as my version of autogen.sh does) overwrites
Gary> these changed files with the normal configuration scripts which
Gary> install without the version postfix.

On Mon, May 11, 1998 at 03:27:06PM -0400, Owen Taylor <Owen> wrote:
Owen> The standard autogen.sh distributed with GTK+ does not rerun 
Owen> libtoolize. For a number of reasons:
Owen> 
Owen>  - It is not necessary. Unlike automake, or autoconf, the output
Owen>    does not depend on other files in the distribution that might
Owen>    be modified.
Owen> 
Owen>  - We'd rather not have to track down bugs in libtool, so we, 
Owen>    if possible, stick with stable releases.

I have libtool-1.2a, and consequently the libtool.m4 used by the aclocal
program (as run by the distributed autogen.sh) causes automake to pass
additional (1.2a only) options to the libtool script.  So, infact it *is*
necessary to run libtoolize before aclocal, unless you have the same
version of libtool as the developer =(O|

I added that step to my autogen.sh for that reason.

Owen> So unless Matt is also running a modified autogen.sh, I don't think
Owen> this is his problem. It might be more likely that autogen.sh wasn't
Owen> run at all, or for some other reason libtool wasn't regenerated.

That is probably true, but I suspect that having a different (or absent)
libtool.m4 than the maintainer of the gnome-*/support directory would cause
similar problems, and maybe running libtoolize is the solution?

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

Owen> The above paragraph gives the perhaps somewhat misleading impression
Owen> that libtool does something unusual with the -soname option.
Owen> 
Owen> In fact, libtool's merely uses -soname (on ELF platforms) to emulate a
Owen> versioning system where a binary linked with libfoo.so.x.y.z can
Owen> be used with libfoo.so.x'.y'.z' if x = x', and y' >= y.
Owen> 
Owen> Then it uses that system in a somewhat more complicated manner. Now,
Owen> there is nothing horribly wrong with libtools versioning scheme,
Owen> in fact:
Owen> 
Owen>  The current versioning scheme is exactly libtool's versioning
Owen>  scheme, except that we add -$(MAJOR)-$(MINOR) to the library
Owen>  names and start over for each major.minor pair.

This is true.  But it still seems like an additional layer of complexity,
particularly because of the redundancy.  Now you need to maintain *five*
numbers, and have added extra rules to determine what happens to these
numbers between releases.  Surely if the rules governing the relationships
between *three* numbers (as advocated by the vanilla libtool library
versioning) are adequate, anything more is unnecessary?

Owen> The unmodified libtool scheme has the disavantage that gtk+-1.1
Owen> would immediately have version number libgtk.so.2.0.0, and
Owen> if we properly mantained versioning in the development branch,
Owen> gtk+-1.2 would end up with a version number libgtk.so.10.0.0,
Owen> or so. (gtk+-2.0, probably libgtk.so.25.0.0)
Owen> 
Owen> Many people would say that there is nothing wrong with
Owen> such version numbers. It is it however, quite noticeable,
Owen> that version numbers that don't look anything like the
Owen> package version numbers cause considerable confusion.

I am one of those people =)O|

I do see your point though.  But... as libtool is adopted by more GNU
package maintainers, people will become more aware that the version numbers
of their libraries do not constitute the version of the package they came
from, which can only be a good thing.  I would hope that maintainers won't
slow this process by schemes such as this

	lib$PACKAGE-$PKGMAJOR.$PKGMINOR.so.$MAJOR.$AGE.$REVISION


From the libtool info (slightly out of context, granted):
   **Never** try to set the interface numbers so that they correspond
   to the release number of your package.  This is an abuse that only
   fosters misunderstanding of the purpose of library versions.  Instead,
   use the -release' flag (*note Release numbers::.), but be warned that
   every release of your package will not be binary compatibility with any
   other release.

Which I take to mean that the library versioning should *not* be maintained
in the development branch, only upon releases.  The individual numbers could
increment by no more than 1 per minor release, so gtk+ would install

  libgtk.so.2.0.0
  
if binary compatibility was broken, otherwise (hypothetically)

  libgtk.so.1.1.1
  
Owen> So, our hope was that a version name:
Owen> 
Owen>  libgtk-1.2.so.0.0.0
Owen> 
Owen> Would make it clear that it is part of the GTK+-1.2.0 package,
Owen> while retaining the ability to convey the necessary versioning
Owen> information in the shared library version numbers (0.0.0)

But what if gtk-1.3 is binary compatible with gtk-1.2?  It would be a shame 
if I had to keep both library versions installed or recompile all my apps
when the versioning scheme should be capable of telling the runtime linker
that the apps linked with gtk-1.2 libraries can take advantage of fixes
and enhancements in gtk-1.3 without relinking.  I might as well use static
libraries.

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

I would cast my vote *against* this scheme, at least for released versions.
I concede that a way to maintain order in the development tree is required,
but I don't think that this is it.  On the other hand, I don't know what it
is either =)O|

Thanks for the reply,

	Gary V. Vaughan

-- 
  ___              _   ___   __              _             
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___ 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
PGP Key from/___/                      /___/               
http://www.cl.cam.ac.uk/PGP/pks-commands.html#extract      
http://pgp.ai.mit.edu/~bal/pks-commands.html#extract

PGP signature