Daniel Stenberg wrote:
> On Thu, 8 May 2008, Doug Goldstein wrote:
>
>> Since I wasn't on the ML at the time of this e-mail being sent.
>
> Ah there he is. Thanks for responding here!
>
>> Now the reason why it would give you warnings when building with icc
>> 10.1 is simple. icc 10.1 is the latest Intel C Compiler available at
>> this current time. However, you're using an old autotools chain
>> (autoconf, automake, libtool, m4, etc) on your system that is not
>> aware of options flag changes in the latest version of icc.
>
> Surely AC_PROG_CC_STDC just requires a new enough autoconf? But the
> failing machine has 2.61 so it's not _terribly_ old either.
>
> I'll contact Tor (owner of that particular build server) and see if he
> might be able to upgrade autoconf and we'll see how that works.
>
Looking into this further, I've found info via Google in response to an
issue with Expat it appears Intel got involved
"the main thing is that Intel wants its compiler to be 100%
compatible with gcc so anyone can easily migrate from gcc to icc. For this
particular option -fexceptions icc is failing to do so. The way icc
interoperate with gcc is by sort of posing as a gcc compiler. icc
predefined some macros that are predefined by gcc (__GNUC__,
__GNUC_MINOR__, __GNUC_PATCHLEVEL__) so icc can be seen as gcc."
This is known to cause some havoc when gcc support isn't 100% spot on...
From the original build log posted..
http://curl.haxx.se/auto/log.cgi?id=20080508012627-10983
checking for gcc... icc
checking whether we are using the GNU C compiler... yes
checking whether icc accepts -g... yes
checking for icc option to accept ISO C89... none needed
checking for icc -c99 option to accept ISO Standard C... (cached) -c99
checking whether icc -c99 and cc understand -c and -o together... yes
checking for icc in use... yes
checking gcc version... icc: command line remark #10010: option '-c99'
is deprecated and will be removed in a future release. See '-help
deprecated'
10.1
Irregardless... the build error that the build complained about is the
fact that "u_char" is not defined along with several other defines.
This type is defined in sys/types.h officially on Linux and FreeBSD.
While it can be found in sys/bittypes.h on other platforms as well.
Linux also provides sys/bittypes.h. It sounds to me like your system
headers are screwy and not defining this... if they are.. this type is
defined to "__u_char" which gcc defines, and if Intel's icc doesn't
define that type then it's not a "gcc compatible" compiler like it's
claiming it is above.
With regard to the other defines, they only appear in
arpa/nameser_compat.h on both Linux and FreeBSD.
According to your build log.. HAVE_ARPA_NAMESER_H and
HAVE_ARPA_NAMESERV_COMPAT_H were not defined for your build process.
This is not something that the previously submitted patches touched so
something else must have changed on that system.
The build log highlights another warning with c-ares however.
ares_process.c uses the strcasecmp() function without actually defining
it. On Linux and on FreeBSD this is defined in strings.h. However the
configure script does not check for the presence of strings.h and
strings.h isn't included in ares_process.c
Received on 2008-05-08