GNOME Bugzilla – Bug 98880
building libxml2-2.4.27 on Solaris
Last modified: 2009-08-15 18:40:50 UTC
Hi, I'm building libxml2-2.4.27 on Solaris 8. While configuring I got the following message: checking resolv.h presence... yes configure: WARNING: resolv.h: present but cannot be compiled configure: WARNING: resolv.h: check for missing prerequisite headers? configure: WARNING: resolv.h: proceeding with the preprocessor's result So I had a look at the config.log: configure:8835: cc -c -O conftest.c >&5 "/usr/include/resolv.h", line 164: warning: dubious tag declaration: struct sockaddr_in "/usr/include/resolv.h", line 171: warning: dubious tag declaration: struct sockaddr_in "/usr/include/resolv.h", line 209: incomplete struct/union/enum sockaddr_in: nsaddr_list "/usr/include/resolv.h", line 219: incomplete struct/union/enum in_addr: addr cc: acomp failed for conftest.c configure:8838: $? = 2 configure: failed program was: #line 8828 "configure" #include "confdefs.h" #include <stdio.h> #if HAVE_SYS_TYPES_H # include <sys/types.h> #endif #if HAVE_SYS_STAT_H # include <sys/stat.h> #endif #if STDC_HEADERS # include <stdlib.h> # include <stddef.h> #else # if HAVE_STDLIB_H # include <stdlib.h> # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include <memory.h> # endif # include <string.h> #endif #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif #if HAVE_UNISTD_H # include <unistd.h> #endif #include <resolv.h> configure:8853: result: no The problem is that on most UNIX systems, one _must_ include BIND related header files in this specific order: #include <netinet/in.h> #include <arpa/nameser.h> #include <resolv.h> Here is an example: $ cat > foo.c #include <netinet/in.h> #include <arpa/nameser.h> #include <resolv.h> $ cc -c foo.c $ $ cat > foo.c #include <arpa/nameser.h> #include <resolv.h> $ cc -c foo.c "/usr/include/arpa/nameser.h", line 124: warning: no explicit type given "/usr/include/arpa/nameser.h", line 124: warning: syntax requires ";" after last struct/union member "/usr/include/arpa/nameser.h", line 124: syntax error before or at: * "/usr/include/arpa/nameser.h", line 124: cannot recover from previous errors cc: acomp failed for foo.c $ $ cat > foo.c #include <netinet/in.h> #include <resolv.h> $ cc -c foo.c "/usr/include/arpa/nameser.h", line 124: warning: no explicit type given "/usr/include/arpa/nameser.h", line 124: warning: syntax requires ";" after last struct/union member "/usr/include/arpa/nameser.h", line 124: syntax error before or at: * "/usr/include/arpa/nameser.h", line 124: cannot recover from previous errors cc: acomp failed for foo.c $
>The problem is that on most UNIX systems, one _must_ include >BIND related header files in this specific order: > >#include <netinet/in.h> >#include <arpa/nameser.h> >#include <resolv.h> *most* seems quite exagerated. Your version of Solaris seems to have the problem but quite a lot of people are compiling on Solaris and don't report this so far. Check with Gary Pennington, he might have an idea of what's happening and a fix for it. I can't reproduce it myself, http://garypennington.net/libxml2/ In any way this doesn't seems directly libxml2 related, maybe there is a workaround, but the problem seems to lie in Solaris header files or changes in the autoconf tools. I take patches, but I can't debug it. Daniel
> +>The problem is that on most UNIX systems, one _must_ include > +>BIND related header files in this specific order: > +> [...] > + *most* seems quite exagerated. Your version of Solaris seems Not at all exagerated. That's out of experience. That's also widely documented: http://www.sas.com/service/library/onlinedoc/sasc/doc700/html/lr2/zr2bsdhf.htm http://www.phekda.freeserve.co.uk/richdawe/lsck/doc/lsck.htm#res_init http://docs.sun.com/db/doc/806-0628/6j9vie7u7?a=view http://docs.hp.com/hpux/onlinedocs/B2355-90695/00/01/127-con.html http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat3c/resolver.z Most UNIX systems used to need that - maybe that's related to old releases of BIND. > +to have the problem but quite a lot of people are compiling on > +Solaris and don't report this so far. This is bug report against libxml2-2.4.27. It has just been released, I doubt quite a lot of people have compiled it on Solaris This seems to be new to libxml2-2.4.27. I don't remember such a problem with earlier releases such as libxml2-2.4.20. Has the autoconf version been upgraded between libxml2-2.4.20 and libxml2-2.4.27? Also maybe libxml2 is usually built with the GNU compiler? I'm using the Sun compiler. > + Check with Gary Pennington, he might have an idea of what's > +happening and a fix for it. I can't reproduce it myself, > + > + http://garypennington.net/libxml2/ Is he a libxml2 maintainer? If so would it be possible to just reasign this bug report to him, instead of starting a bug report from scratch? Dimitri
>This is bug report against libxml2-2.4.27. It has just been released, >I doubt quite a lot of people have compiled it on Solaris I didn't touch the configuration part for this release, at least nothing related to header includes that I can remember. >This seems to be new to libxml2-2.4.27. I don't remember such a >problem with earlier releases such as libxml2-2.4.20. Has the autoconf >version been upgraded between libxml2-2.4.20 and libxml2-2.4.27? yes, as I said it might be an autoconf bug. >> + Check with Gary Pennington, he might have an idea of what's >> +happening and a fix for it. I can't reproduce it myself, >> + >> + http://garypennington.net/libxml2/ > >Is he a libxml2 maintainer? If so would it be possible to just reasign >this bug report to him, instead of starting a bug report from scratch? Gary works on the Sun Solaris kernel team. He also package libxml2 for solaris. Point him to this bug. He is not a Gnome developper, I can't reassign the bug to him, and again I do not think it's a Gnome bug, either something special in your environment trigered it or the autoconf tools changed. I both case I don't have any way to handle it myself, but again, I take patches. If you wanted to be proactive, since you know portability so well and have the priviledge to be the first experiencing it try to tweak the configure.in file to check for the other headers first and see if it fixes the problem. And again I cannot test the issue ! Daniel
> yes, as I said it might be an autoconf bug. It is an autoconf bug indeed. autoconf was upgraded from 2.13 to 2.53 for libxml2-2.4.27. Gary can reproduce my problem libxml2-2.4.27. He says the symptom disappears when reverting to autoconf 2.13 and regenerating configure from configure.in. I have upgraded to autoconf 2.56 and regenerated configure from configure.in. This doesn't fix the problem but adds an explicit message that shows this is a known autoconf bug: configure: WARNING: resolv.h: present but cannot be compiled configure: WARNING: resolv.h: check for missing prerequisite headers? configure: WARNING: resolv.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I'll report this to the autoconf team and let you know when they have a fix.
Yes, the point is that libxml2 configure.in do check first for the headers needed, precisely: AC_CHECK_HEADERS(stdlib.h sys/socket.h netinet/in.h arpa/inet.h) AC_CHECK_HEADERS(netdb.h sys/time.h sys/select.h sys/mman.h) AC_CHECK_HEADERS(sys/timeb.h signal.h arpa/nameser.h resolv.h) i.e. before getting to resolv.h, netinet/in.h and arpa/nameser.h are checked first. And the configure.in has done this for years... I stick with RESOLVED NOTGNOME as the resolution for this bug :-\ Daniel
> i.e. before getting to resolv.h, netinet/in.h and arpa/nameser.h > are checked first. And the configure.in has done this for years... Unfortunately autoconf has changed, this is not an autoconf bug, but the result of a new feature of autoconf. autoconf will not be fixed. Rather libxml2 needs to be modified and adapted to the new autoconf. I got this reply to my bug report to the autoconf list: > > > <resolv.h> > > This header file contains global definitions for the > > resolver. [...] You must include the <sys/types.h>, > > <netinet/in.h>, and <arpa/nameser.h> header files > > before this header file. > > This clearly explains why autoconf refuses to accept your resolv.h. > > You might want to read what autoconf.info says about the 4th > parameter (INCLUDES) to AC_CHECK_HEADER and AC_CHECK_HEADERS. So I had a look at autoconf.info and found this: +> +> Previous versions of Autoconf merely checked whether the +> header was accepted by the preprocessor. This was changed +> because the old test was inappropriate for typical uses. +> Headers are typically used to compile, not merely to preprocess, +> and the old behavior sometimes accepted headers that clashed at +> compile-time. If you need to check whether a header is +> preprocessable, you can use `AC_PREPROC_IFELSE' (*note +> Running the Preprocessor::). +> +> This scheme, which improves the robustness of the test, also +> requires that you make sure that headers that must be included +> before the HEADER-FILE be part of the INCLUDES, (*note Default +> Includes::). If looking for `bar.h', which requires that `foo.h' +> be included before if it exists, we suggest the following scheme: +> +> +> AC_CHECK_HEADERS([foo.h]) +> AC_CHECK_HEADERS([bar.h], [], [], +> [#if HAVE_FOO_H +> # include <foo.h> +> # endif +> ]) So libxml2 needs to be fixed to work properly with new versions of autoconf, or keep using older versions of autoconf.
Created attachment 12399 [details] [review] fixed configure.in for libxml2-2.4.17
The patch is of course against libxml2-2.4.27, not libxml2-2.4.17. Sorry. It follows exactly the header dependencies described here: http://www.sas.com/service/library/onlinedoc/sasc/doc700/html/lr2/zr2bsdhf.htm as well as the autoconf.info recommendations.
Okay, applied, thanks, Daniel
Okay I think we can close it with release 2.4.28, Daniel