Hi Bob.
On Thu, Apr 27, 2000 at 03:26:42PM -0400, Bob Bell wrote:
>
> AFAICT, I'm bumping into problems with the versioning technique
> libtool uses. Here's my (variable names expanded) libintl_a_LDFLAGS:
> libintl_la_LDFLAGS = -version-info 0:35:0 -release 0.10 -export-dynamic
You probably shouldn't be using -release, which is for libraries like
tcl/tk and gtk which name their libraries libgtk-1.2.so, for example.
Forcing release numbers into library versions is generally a bad idea,
and *will* cause headaches later on.
> This is meant to reflect the 0.10.35 version of gettext/libintl. I
> am doing something wrong? Is there anyway to get my existing programs
> to work with my libtool-ized libintl, or do I have to recompile all my
> programs to accept the new versioning?
That would be the right way to tackle it. You should start with a
library version that is "higher" than the last official release, and
go with that. It is up to the gettext maintainer to track interface
changes with subsequent releases after that so that ld.so has the
information it needs.
> I'd hate to have to do the latter, especially as it would likely get
> rejected by the gettext maintainer.
Technically, you could reverse engineer the libtool -version arguments
to produce a .so library suffix which matches the current gettext
version. But I would strongly recommend you don't. The library
version numbers are to help ld.so find the newest compatible version
of a library for an application that was compiled with an arbitrary
earlier version. The package release number is to help *you* decide
whether you want to upgrade the release you are running at the moment.
They are not the same, and forcing one to look like the other is a big
(but common) mistake.
Perhaps you can persuade the gettext maintainer to accept your
changes, so that ld.so can use library version numbers properly
starting at the next release. As a counter example, libglib uses the
-release flag, and forces binary incompatibility between releases
(libglib-1.0.so vs. libglib-1.2.so) and a recompile of *all*
applications, when in reality the changes were binary compatible, and
had the maintainer been using libtool versioning correctly, would have
allowed users to install a new libglib.so such that ld.so would have
been able to automatically load the newer release without recompiling
any applications.
Cheers,
Gary.
--
___ _ ___ __ _ mailto: [EMAIL PROTECTED]
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
