On Thu, 19 Feb 2004, I wrote:
[icc detected as gcc]
[...]

On Feb 19, 22:38, Daniel Stenberg wrote:
[...]
>I've now tried to detect this by checking for a too high version number.
>Anything 5.0 or above is not treated as gcc anymore.

That fix seems to work fine. It's not applied to ares/configure.ac yet,
so we're still seeing the stuff below:

icc -c -DCURLDEBUG -I../include -g -g -W -Wall -Wwrite-strings -pedantic -Wundef
 -Wpointer-arith -Wnested-externs -Wcast-align -Winline -Wstrict-prototypes -Wmi
ssing-declarations -Wmissing-prototypes -Wshadow -Wsign-compare -DPACKAGE_NAME
=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACK
AGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 ../../curl/ares/ares__close_sockets.c
icc: Command line remark: option '-W' not supported
icc: Command line warning: ignoring option '-p'; no argument required
icc: Command line warning: ignoring option '-W'; no argument required
icc: Command line warning: ignoring option '-W'; no argument required
...

*However*, I've done some more testing and for some reason autoconf apparently
detects that the Intel compiler isn't GCC on my i386 box, while it fails to
do so on my ia64 box.

i386:
checking for gcc... icc
checking dependency style of icc... none
checking whether we are using the GNU C compiler... no
ia64:
checking for gcc... icc
checking dependency style of icc... gcc
checking whether we are using the GNU C compiler... yes

Versions of autoconf and libtool are the same on the two boxes, while
automake is currently 1.7.4 on ia64 and 1.8.2 on i386. But I did try
with 1.8.2 on ia64 earlier, with the same result.

I'm going to look into this, if icc could properly be detected as a non-GNU
compiler then it shouldn't be necessary to add the gcc version hack to
the ares autoconf, and it could be removed from the curl autoconf.
I'll post here if I manage to figure it out.

-Tor
Received on 2004-02-23