Re: linking against a particular version of a library

[Ralf Wildenhues]

[ resend because of typo in mail address ]

Hi Ross,

* Ross Boylan wrote on Tue, Dec 20, 2005 at 11:44:43PM CET:
> Suppose I wish to link a program against a particular version of a
> library.  Is there a way to do that in libtool?

Generally, no.  `-release' in combination with `-lfoo-1.2' is only a
cludge around this, IMHO.

> Is there a way to do it even if the libraries themselves are not
> libtoolized?

Same issue as above.

Well, on GNU/Linux the important name while creating the program is the
unversioned symlink of the library: your program will link against this.
So, you could change the unversioned symlink in order to choose which
version to link against.  Note this is not portable in any way, so this
will fail on several other systems; also, there may be other ways on
other systems, too.

> The documentation discusses how to indicate the version of a library,
> but I didn't see much on how a program can specify what library versions
> it needs.  Perhaps in the examples discussed that is derived implicitly
> from the libraries linked against?

No, it is expected that users always want to link against the newest
library version, when creating programs.

> Background: I'm working on systems with several versions of boost
> libraries installed.  I don't think boost uses libtool. These are sets
> of libraries with names like libboost-foo-1_33.a
> libboost-foo.a points to or is the most current version.
> 
> Suppose I want to use an older version, e.g., 1_31.  I there a way to
> tell this to boost other than coding boost-foo-1_31 as the library name?

Not that I know of (but I don't know darwin well), if creating an
unversioned symlink does not help.

> Unfortunately, the naming convention seems erratic.

Well, what can we do about that?  ;-)


One thing I have done before to circumvent this issue without losing too
much flexibility is the following:  Suppose I have libfoo in several
different versions (and suppose, for notational purposes, that libfoo
uses Automake[1]).  For each set of incompatible versions, choose a
different prefix, say /opt/packages/foo-1, /opt/packages/foo-2.
For each compatible prefix, configure like

  cd foo-source-1.1
  ./configure --prefix=/opt/packages/foo-1
  make
  make install DESTDIR=/tmp/dest
  mkdir /opt/packages/foo-1.1
  mv /tmp/dest/opt/packages/foo-1/* /opt/packages/foo-1.1/

  cd foo-source-1.2
  ./configure --prefix=/opt/packages/foo-1
  make
  make install DESTDIR=/tmp/dest
  mkdir /opt/packages/foo-1.2
  mv /tmp/dest/opt/packages/foo-1/* /opt/packages/foo-1.2/

Then, create symlinks from foo-1.current to foo-1.  When configuring
dependent packages, use LDFLAGS=-L/opt/packages/foo-1/lib to find
libfoo.

This way you can have several incompatible versions simultaneously,
while you need only the newest one of compatible versions installed.
I agree that it may be more useful in some cases to
  ./configure --prefix=/opt/packages/foo-1.2

which will also allow the compatible versions to live simultaneously
(but will also prevent you from removing older compatible versions,
because dependent programs will still have that path hardcoded).

I agree that it's all a mess (for example, because it does not work
well if one package distributes several libraries that have incompatible
changes in different versions).  I don't know of a way out that is
reasonably portable, though, and what's more, I don't know of a way
that is suitable for distributions, where most or all should live under
/usr/lib, for example; they usually resort to either a flag day, or put
the unversioned symlinks, static libs, and .la files into versioned
development packages, together with the headers.

Cheers,
Ralf

[1] Note that with many packages, the sequence may be simplified to
  cd foo-source-1.1
  ./configure --prefix=/opt/packages/foo-1
  make
  make install prefix=/opt/packages/foo-1.1
Both sequences require that the libfoo package follows the corresponding
GCS rules for $DESTDIR and $prefix closely; the latter may not work with
all `make' implementations, in which case
  prefix=/opt/packages/foo-1.1 make -e install
*may* work better (given the usual precautions for `make -e').