Hi Max,
How will setting CPPFLAGS or LDFLAGS from the svn build programs will
affect the neon configure routine?
My patch calls the neon's configure with the LDFLAGS/CFLAGS values as
seen by svn build programs from apr-util.
Unfortunately I could not reproduce the same issue now as I did sometime
back. Yes I could reproduce now but my very restrictive '-nostdinc' to
CFLAGS and CPPFLAGS causes someother compile issue which it did not in
the past. Will try and get back.
With regards
Kamesh Jayachandran
Max Bowsher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kamesh Jayachandran wrote:
>
>> Hi Garrett,
>> Thanks for your feedback.
>> Based on comment on this defect by maxb sometime this january to make
>> use the apu-config --includes and apu-config --ldflags, modified the
>> patch and tested by having two installations of expat one in the
>> /usr/local and another in the /home/kamesh/expat and made the CFLAGS to
>> have -I/home/kamesh/expat/include to influence the neon to take the
>> expat from /home/kamesh/expat while apr-util take it from /usr/local/lib.
>> With this patch apr-util always dictates what version of expat neon says.
>> Ran make check which went through fine.
>>
>> [[[
>> Fix issue #699, XML parser not detected at configure time
>> * build/ac-macros/neon.m4
>> Configure neon block
>> There is a difference in the way expat(actually expat.h) is
>> identified in the build system between the apr-util and neon.
>> The apr-util explicitly identifies the expat in /usr, /usr/local.
>> The neon hands off the task to AC_CHECK_HEADER autoconf macro
>> which just relies on the default behaviour of
>> $(CC), $(CFLAGS) $(CPPFLAGS) which seems to be fine in my gcc
>> version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
>> Because of this difference possibly both might find a different
>> versions of expat.
>> The fix feeds the findings of apr-util to neon.
>> ]]]
>>
>> Index: build/ac-macros/neon.m4
>> ===================================================================
>> --- build/ac-macros/neon.m4 (revision 17664)
>> +++ build/ac-macros/neon.m4 (working copy)
>> @@ -79,6 +79,17 @@
>> # there, otherwise, neon is on its own to find expat.
>> if test -f "$abs_builddir/apr-util/xml/expat/lib/expat.h" ; then
>> args="$args --with-expat='$abs_builddir/apr-util/xml/expat/lib/libexpat.la'"
>> + else
>> + #There is a difference in the way expat(actually expat.h) is identified in the build system between the apr-util and neon.
>> + #apr-util explicitly identifies the expat in /usr, /usr/local
>> + #neon hands off the task to AC_CHECK_HEADER autoconf macro which just relies on the default behaviour of $(CC), $(CFLAGS) $(CPPFLAGS) which seems to be fine in my gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
>> + #Because of this difference possibly both might find a different versions of expat.
>> + #The below solution feeds the findings of apr-util to neon.
>> + if test -f /usr/local/include/expat.h; then
>> + apr_utils_includes=`$abs_builddir/apr-util/apu-config --includes`
>> + apr_utils_ldflags=`$abs_builddir/apr-util/apu-config --ldflags`
>> + args="$args CFLAGS='$apr_utils_includes $CFLAGS' LDFLAGS='$apr_utils_ldflags $LDFLAGS'"
>> + fi
>> fi
>> SVN_SUBDIR_CONFIG(neon, $args)
>>
>
> Why all this weird special-casing instead of following the suggested
> course of action I described in issuezilla?
>
> Max.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Cygwin)
>
> iD8DBQFDvSMPfFNSmcDyxYARAm21AJ9hp7bRH9AUsZP5IUvB7anayImCgACguYkI
> VsrX9YHUYgqy9voHHmjrmLA=
> =YIPE
> -----END PGP SIGNATURE-----
>
>
Received on Fri Jan 6 15:58:25 2006