apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Jen <slow...@gmail.com>
Subject Re: Patch for checking expat on Solaris
Date Wed, 03 May 2006 09:23:01 GMT
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)


View raw message