Peter Breitenlohner wrote: > 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'. > I agree that this is one solution, and Ralf's suggestion about LDFLAGS is also valid of course. I didn't see any example in the documentation endorsing a particular approach, and every project I've looked at seems to handle the problem in a slightly different way. Of course maybe many of them are a little broken. There is another case that we handle as well: some libs provide a -config script, e.g. apr-1-config, so you can specify ./configure --with-libapr=/opt/apr-1/bin/apr-1-config and configure will interrogate apr-1-config to get the LDFLAGS and CFLAGS _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
