Subject: Re: [ecasound] embedding interface version numbers in library names
From: Kai Vehmanen (k_AT_eca.cx)
Date: Sat Apr 27 2002 - 23:27:18 EEST
On Thu, 25 Apr 2002, Michael Carmack wrote:
>> When linking you can give only one -rpath option
>> to the linker. That means you can only give one
>> library directory not in /etc/ld.so.conf.
> Are you sure about this? /etc/ld.so.conf doesn't even exist on my
> systems, and I routinely compile with multiple -rpath specifications.
No. :) I guess I've been using automake+libtool for too long. So yes,
you're right, you can specify multiple rpaths when using ld. With the
automake+libtool that ecasound uses, rpath is never explicitly specified.
When creating libraries, rpath is set to the directory the library will
eventually be installed to. For binaries, libtool adds a rpath for each
library.
From automake info docs:
--cut--
The `-rpath' option is passed automatically by Automake (except for
libraries listed as `noinst_LTLIBRARIES'), so you should not specify it.
--cut--
Another, somewhat related, libtool problem is that inter-library
dependencies are given as simple "-llib1 -lib2 -llib3" lists. It's not
possible to specify the runtime paths for each external library. This
means that when linking against library xxx, you'd somehow have to know
the rpaths of each external library that xxx depends on. This limitation
is not entirely libtool's fault. Some platforms are very limited when it
comes to inter-library dependencies.
I just tried adding another -rpath to libecasound's LDFLAGS, and got this
(libtool 1.4.2; the latest stable version):
--cut--
libtool: link: warning: ignoring multiple `-rpath's for a libtool library
--cut--
Yet another source of problems is the lack of explicit support for library
versioning. Libtool doesn't offer a way to "link against library X,
interface number Y" (and neither does GNU ld). Instead you have to say
"link against library X", and hope that the first instance of X that the
linker finds happens to be Y. And to make matters worse, link-time
(-L/path/to) and runtime (-rpath and /etc/ld.so.conf) paths are not
necessarily the same.
With your pkg-system this is resolved by not having any library versions
outside the pkg-hierarchy. But there's still the problem of how to select
which library version to use. You could either specify the path to some
specific version or modify the symbolic links.
And here's where embedded version numbers to library names become useful
(even in your pkg-system). Let's say you have the following situation:
ecasound 2.0.4 uses libecasound7
ecasound 2.1dev8 uses libecasound8
Then you want to installe ecawave 0.4.1, which requires libecasound7. With
the new embedded versions system, ecawave's configure script will look for
script 'libecasound7-config' to find the header and library files. This
makes it explicit that this specific version of ecawave is to be used only
with libecasound7, not anything else. In the pkg-system, you could have
all 'libecasoundX-config' in the user's PATH, while the packages
themselves are installed to '/pkg/ecasound/2.x.y/'. As a result, compiling
apps that require different versions of libecasound works out-of-the-box.
PS If libtool has so many problems, why use it at all? Well, without
libtool you're facing:
http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html
Not a pretty sight. ;)
> BTW, if this is getting off-topic I don't mind continuing in private.
> I'm curious if I understand your second assertion correctly though.
Still quite on-topic as far as I'm concerned. :)
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Sat Apr 27 2002 - 23:13:05 EEST