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): How reproducible: Always Steps to Reproduce: 1.Take any source which use the AM_PATH_XML2() macro to detect libxml2 in its configure.in 2.Attempt to run the sources configure script 3. Actual Results: The configure script for the package in question produced the following output: 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) Additional info:
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 Daniel
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, Daniel
Agreed, thanks for the clarification. I note that the m4 macro in libxml2 2.4.20 already addresses this issue. Thanks again.
Yes this was fixed on-purpose trying to put it in time for the release, yours, Daniel