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 Sat, 29 Apr 2006 02:06:07 GMT
On 4/10/06, Henry Jen <henryjen@ztune.net> wrote:
>
> 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.



I meant to say Solaris default linker does not behave the same as GNU ld.
-R is recommended practice on Solaris. crle or LD_LIBRARY_PATH can do the
trick, but those practice are discouraged.

> 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.



Attached please find a new patch using AC_CHECK_LIB to find the correct
library path.


Cheers,
Henry

Mime
View raw message