Joe Orton wrote:
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.
Hmm, it won't because there is a break for the first match. Otherwise,
no result is set.
- 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.
OK, what if it is not link against with libexpat.la but a libexpat.so?
My experiment on Solaris does not add -R automatically. (Solaris only
provides libexpat.so, no libexpat.la)
Cheers,
Henry
