apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Jen <henry...@ztune.net>
Subject Re: Patch for checking expat on Solaris
Date Mon, 10 Apr 2006 23:32:32 GMT
William A. Rowe, Jr. wrote:
> Henry Jen wrote:
>>
>> +  elif test -r "$1/include/expat.h"; then +    dnl Expat 1.95.* 
>> installation (without libtool)
>> +    dnl Solaris
>> +    expat_include_dir="$1/include"
>> +    expat_ldflags="-L$1/lib -R$1/lib"
>> +    expat_libs="-lexpat"
> 
> Here's my essential problems with growing this cruft further :(
> 
> -L and -R should be redundant, no?  

No, they are not. -L is for link time, -R for runtime. For the default
linker on Solaris, the -R is taking the value from -L as gnu ld.

> Further, there's this lovely assumption
> that because we find an expat .h in X/include/ we infer without any testing
> whatsoever there is a ld in X/lib.
> 
> These sorts of fragile assumptions *throughout* the build system (not 
> singling out specifically your patch), e.g. the old uuid detection code, 
> ongoing debates
> about lib64 (you assume $1/lib, how do you know X/include/ isn't 
> X/lib64/'s?)
> Make me really hesitate to touch the code further without a real 
> test-compile
> and test-link as the new uuid code performs (before bailing with 'I 
> surrender!')
> 

Thank you for the feedback, I will redo the patch.

IMHO, we should do AC_CHECK_LIB with the default LDFLAGS/CFLAGS appended 
by the value of --with-expat suffixed with /include|/liband then make 
sure those flags are passed into the result Makefiles.

Depending on the .a or .la file is in the place and readable is not more 
correct, I would think. Even if we want to do that, should we check for 
.so rather than .la or .a? Because the .a or .la should not be necessary 
if the libexpat.so is built correctly. Take the Solaris example, there 
is no .la or .a, only .so exist in /usr/sfw/lib, and the link will succeed.

Cheers,
Henry

Mime
View raw message