Red Hat Bugzilla – Bug 64134
Autoconf m4 macro provided does not work as includes have been moved relative to previous version.
Last modified: 2008-08-01 12:22:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020401
Description of problem:
The includes for this version of libxml2 are installed in
/usr/include/libxml2/libxml, whereas previous versions were installed in
/usr/include/libxml. The xml2-config script gives the required cflags as
"-I/usr/include/libxml2", and the test program in /usr/share/aclocal/libxml.m4
tests for the presence of libxml version 2 by attempting to include
xmlversion.h. This test fails because the file in question is not on the given
include search path. The test can be made to succeed by hacking the test macro
to check for libxml/xmlversion.h instead.
Even if the test is hacked, source which built with previous versions of libxml2
will not build with this version.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Take any source which use the AM_PATH_XML2() macro to detect libxml2 in its
2.Attempt to run the sources configure script
Actual Results: The configure script for the package in question produced the
checking for libxml - version >= 2.3.5... no
*** Could not run libxml test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means LIBXML was incorrectly installed
*** or that you have moved LIBXML since it was installed. In the latter case, you
*** may want to edit the xml2-config script: /usr/bin/xml2-config
Expected Results: The configure script for the package in question should have
produced this output:
checking for libxml - version >= 2.3.5... yes (version 2.4.19)
Libxml2 include files must be stored in $prefix/include/libxml2
Libxml1 include files must be stored in $prefix/include/gnome-xml
Anything present in $prefix/include/libxml is an error and MUST be removed.
The way to gather the include flags (and libraries) for libxml2 and libxml
is to query xml2-config and xml-config respectively. I do not support
the AM_PATH_XML2/AM_PATH_XML autoconf constructs since I'm unable to
figure out how to maintain or debug them.
If you have a specific suggestion on how to fix AM_PATH_XML? I take patches
but again it is not the supported way to get compile-time and link-time
flags for libxml and libxml2
The AM_PATH_XML2 macro uses xml2-config to gets its include flags.
The problem is that the tests, and most software I have come across, expect
xml2-config to give them the full path for the directory which contains
the libxml2 header files, which in this case is /usr/include/libxml2/libxml,
but xml2-config only returns /usr/include/libxml2. If this change is
intentional, then the m4 macro can be fixed by changing the line that includes
xmlversion.h to include libxml/xmlversion.h, and source which uses libxml2 will
need to be modified. I will be happy with either a fix to xml2-config, or a
clarification that the output of xml2-config is correct, and source needs to be
changed. Thanks for the fast response.
libxml2-2.4.10-0.7x.2 exhibits what I believe is the correct behavoir.
Includes are in /usr/include/libxml2/libxml.
xml2-config --cflags give this following:
-I/usr/include/libxml2/libxml -I/usr/include/libxml2 -I/include
No, the libxml2 include path *MUST* be $prefix/libxml2
Applications *MUST* include the headers as #include <libxml/tree.h>
Trying to include directly <tree.h> or <parser.h> for examples
conflicts with the namespace of of some code C++ classes (STL for example).
I confirm that the behaviour of xml2-config --cflags is correct and that
your code must be modified to use the fully namespaced include path,
This is NOT a bug,
Agreed, thanks for the clarification.
I note that the m4 macro in libxml2 2.4.20 already addresses this issue.
Yes this was fixed on-purpose trying to put it in time for the release,