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
