[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Finding dependencies in lib64 or lib
From: |
Peter Breitenlohner |
Subject: |
Re: Finding dependencies in lib64 or lib |
Date: |
Thu, 11 Feb 2010 15:36:36 +0100 (CET) |
User-agent: |
Alpine 2.00 (LNX 1167 2008-08-23) |
On Thu, 11 Feb 2010, Daniel Pocock wrote:
It is not quite so simple - the third party library may be installed
elsewhere, e.g. /opt/confuse-2.6/lib64
The --with-libconfuse option only accepts the base directory (e.g.
--with-libconfuse=/opt/confuse-2.6) and configure has to decide whether
to append /lib or /lib64 to find the right dependencies.
This use of '--with-libconfuse' to derive both -I and -L flags may be
traditional, but for bi-arch systems with, e.g. lib and lib64, this is just
a broken design. [And there may be other reasons why headers and libraries
are not in FOO/include and FOO/lib with the same prefix.]
IMHO a sane way is to use two options '--with-libconfuse-include' and
'--with-libconfuse-libdir' or some such.
And for backwards compatibility one could interprete '--with-libconfuse=DIR'
as '--with-libconfuse-include=DIR/include --with-libconfuse-libdir=DIR/lib'.
On some systems (e.g. a host used for building 32 and 64 bit packages),
there may be two versions of libconfuse installed, e.g.
/opt/confuse-2.6/lib/libconfuse.so (32 bit)
/opt/confuse-2.6/lib64/libconfuse.so (64 bit)
and our original configure.in would never look in the 64 bit directory.
About time to modify your configure.in as outlined above.
Regards
Peter Breitenlohner <address@hidden>
Re: Finding dependencies in lib64 or lib, Konstantin Andreev, 2010/02/11
- Re: Finding dependencies in lib64 or lib, Ben Taylor, 2010/02/11
- Re: Finding dependencies in lib64 or lib, Dr. David Kirkby, 2010/02/17
- Re: Finding dependencies in lib64 or lib, Dr. David Kirkby, 2010/02/17
- Re: Finding dependencies in lib64 or lib, Ralf Corsepius, 2010/02/17
- Re: Finding dependencies in lib64 or lib, Ben Taylor, 2010/02/17
- Re: Finding dependencies in lib64 or lib, Bob Friesenhahn, 2010/02/17