[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Fix for #699 XML parser not detected at configure time

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2005-12-08 07:23:16 CET

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.
apr-util searches for the expat in */usr /usr/local* xml/expat-cvs
xml/expat $srcdir/xml/expat.
_Snippet from apr-util/build/apu-conf.m4_
if test -z "$expat_include_dir"; then
  for d in /usr /usr/local xml/expat-cvs xml/expat $srcdir/xml/expat ; do
    APU_TEST_EXPAT($d)
    if test -n "$expat_include_dir"; then
      dnl For /usr installs of expat, we can't specify -L/usr/lib
      if test "$d" = "/usr"; then
        expat_ldflags=""
      fi
      break
    fi
  done
fi

Whereas neon leaves the job of finding the expat libs to
AC_CHECK_HEADER/AC_CHECK_LIB both being influenced by the $CFLAGS,
$CPPFLAGS. This issue is not reproducible straight forward atleast in my
RHEL the gcc getting shipped along seem to be searching for headers in
/usr/include /usr/local/include without me specifying by
-I/usr/local/include.

As I could see only the difference being /usr/local between neon and
apr-util. This patch plugs the difference in case apr-util identifies
the system expat libs a nd that happened to be in /usr/loca/... which
would be ignored by neon on a possible old compiler which won't search
in /usr/local/include.

Anyway updated the issuezilla for this defect how to reproduce.
Made the comments multiline and removed the steps to reproduce.

Regarding expat elsewhere anyway user needs to specify it with
--with-expat switch.

With regards
Kamesh Jayachandran
Garrett Rooney wrote:
> On 12/7/05, Kamesh Jayachandran <kamesh@collab.net> wrote:
>
>
>> The fix actually runs the configure for neon with CFLAGS and LDFLAGS set to
>> /usr/local/include /usr/local/lib respectively for this special case if we
>> can see the /usr/local/include/expat.h.
>>
>
> Why should we be hardcoding a special case for /usr/local? It seems
> kind of silly to special case one location like that when for all we
> know expat could have been installed virtually anywhere. Is there any
> reason you went with this approach as opposed to following Max
> Bowsher's suggestion in the issue about adding apu-config --cppflags
> to CPPFLAGS and thus getting the benefit of finding the exact expat
> that APR found?
>
>
>> + else
>> + #Fundamentally 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 whereas 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) to identify expat located in /usr/local. Anyway could reproduce
>> the issue with the following command line after renaming all the instances
>> of xml-config, xml-config2, expat.h libxml2.so, libxml.so, libexpat.so in
>> /usr/include and /usr/lib dir and copying the libexpat.so and expat.h to
>> /usr/local/lib and /usr/local/include respectively.
>> + #./configure CFLAGS='-nostdinc -I/path/to/build/dir/neon/
>> -I/usr/include -I/usr/lib/gcc/<Your vendor info>/<Your gcc-version>/include
>> -I/usr/include/linux' CPPFLAGS='-nostdinc -I/usr/include
>> -I/usr/include/linux'
>> + if test -f /usr/local/include/expat.h; then
>> + args="$args CFLAGS='$CFLAGS -I/usr/local/include'
>> LDFLAGS='$LDFLAGS -L/usr/local/lib'"
>> + fi
>> fi
>> SVN_SUBDIR_CONFIG(neon, $args)
>>
>
> That's an awfully long comment... If it does need to be there (and
> I'm positive that the exact command to reproduce doesn't belong there)
> it should at least be broken into multiple lines as the rest of the
> file does, not one long line.
>
> -garrett
>
>

Index: build/ac-macros/neon.m4
===================================================================
--- build/ac-macros/neon.m4 (revision 17664)
+++ build/ac-macros/neon.m4 (working copy)
@@ -79,6 +79,14 @@
           # 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
+ #Fundamentally 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) to identify expat located in /usr/local.
+ #The only effective difference is /usr/local this fix addresses that
+ if test -f /usr/local/include/expat.h; then
+ args="$args CFLAGS='$CFLAGS -I/usr/local/include' LDFLAGS='$LDFLAGS -L/usr/local/lib'"
+ 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 Thu Dec 8 07:25:53 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.