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.
]]]
With regards
Kamesh Jayachandran
Garrett Rooney wrote:
> On 12/7/05, Kamesh Jayachandran <kamesh@collab.net> wrote:
>
>> Hi Garrett,
>> The issue as per my understanding of the issue is that the difference in
>> the way expat libs are detected by apr-util and neon.
>>
>
> And that's the problem I'm seeing with this plan. Sure, you've made
> the search paths the same so if libexpat is located in /usr/local both
> of them will find it there, but it only solves half the problem. You
> still have potential situations where apr-util finds one version of
> expat but neon finds another, that can't be a good thing...
>
> I'm just wondering if it would be better to arrange for neon and
> apr-util to use the same version of expat, at least if we're building
> neon as part of our configure and make process, if we link against a
> prebuilt neon it's out of our hands anyway.
>
> -garrett
>
>
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)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 12 14:39:46 2005