On Tue, May 02, 2006 at 01:10:44PM -0700, Henry Jen wrote: > Joe Orton wrote: > >On Fri, Apr 28, 2006 at 07:06:07PM -0700, Henry Jen wrote: > >>Attached please find a new patch using AC_CHECK_LIB to find the correct > >>library path. > > > >If you want to rewrite this code then look at dbm.m4 for how to do it > >properly. > > > >- you can't just call AC_CHECK_LIB, you need to cache and display > >results properly > > Uh? The result are cached in expat_xxx as they were before. Am I missing > something?
Doing: + for d in $1/lib $1/libdir ; do + CFLAGS="$old_cflags -I$1/include" + LDFLAGS="$old_ldflags -L$d -R$d" + AC_CHECK_LIB(expat, XML_ParserCreate, [ does not work as you might think. AC_CHECK_LIB will cache the test result the first time through the for loop; the second test will always have the same result as the first. > >- the -R flag should really never be used, especially like this - at the > >very least, you can't assume all linkers support it. You generally can > >rely on libtool to add RPATHs iff necessary. > > Hmm, I don't know about how libtool add RPATH. Does it apply to > situation like this(solve dependencies on some other share libraries > without a .la) or it only works for *creating* a .la? libtool will add an RPATH to libaprutil if it is linked against a libexpat.la where the libexpat.la is in a directory which is not in the standard system library search path. Regards, joe
