[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Trouble controlling linking if many library versions are installed
From: |
Rob Browning |
Subject: |
Re: Trouble controlling linking if many library versions are installed |
Date: |
Tue, 19 Mar 2002 08:34:39 -0600 |
User-agent: |
Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i386-debian-linux-gnu) |
Steve Tell <address@hidden> writes:
> In additional experimention, I found that simply removing -L/usr/lib
> altogether works in this case, perhaps because of the --rpath.
> "Correct" for me here is building a libguilereadline.so that depends
> explicitly on the versioned name libguile.so.14 (which I guess will
> be searched for at runtime)
We've had a similar ongoing problem with the foo-config type scripts,
i.e. "foo-config --libs". If any one of them that you're using to
compile a given project produces -I/usr/include or -L/usr/lib, and if
its flags appear on your compile/link line ahead of some other lib,
then its impossible to build your project using a non /usr/lib install
of some library that's also installed in /usr/lib. For example, if
you have guile 1.4 installed in /usr/lib, and you install the guile
1.5 beta into /opt/guile-1.5, you will be unable to compile or link a
gtk app against guile 1.5 if any of the gtk config scripts output
-L/usr/lib and those flags appear before -lguile on the link line.
On Linux and similar systems, could libtool, foo-config scripts,
etc. just special case (and omit) -L/usr/lib -L/lib and
-I/usr/include?
Thanks
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD