Re: AC_LANG_FUNC_LINK_TRY(C): stub detection fails with ICC 10.1

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[revisiting an old thread]

According to Aaron Ucko on 12/24/2008 10:42 AM:

Hello Aaron,

> $ /opt/intel/cce/10.1.021/bin/icc -o conftest conftest.c; echo $?
> conftest.c(6): warning #1224: #warning directive: "What, no PATH_MAX?  What 
> is this, the HURD? ;-)"
>   #    warning "What, no PATH_MAX?  What is this, the HURD? ;-)"
>        ^
> /tmp/ucko/pts_5/iccxqEoau.o(.text+0x22): In function `main':
> : warning: warning: lutimes is not implemented and will always fail
> 0

> There are various ways to turn the warning into an error:
> 
> $ /opt/intel/cce/10.1.021/bin/icc -o conftest -Wl,--fatal-warnings 
> conftest.c; echo $?

Not good, see the recent thread on -Werror not playing nicely with autoconf.

> $ /opt/intel/cce/10.1.021/bin/icc -o conftest -D_GCC_NEXT_LIMITS_H 
> conftest.c; echo $?

Possible.  And probably the simplest approach here.

> $ /opt/intel/cce/10.1.021/bin/icc -o conftest -include gnu/stubs.h 
> conftest.c; echo $?

Is gnu/stubs.h a reliable means for catching declared but unimplemented
functions?  It is obviously not present everywhere, but maybe it makes
sense to check whether that file is present, and if so add it to the list
of headers pulled in by AC_LANG_FUNC_LINK_TRY(C) link checks.

> 
> Of those, I now feel that arranging to #define _GCC_NEXT_LIMITS_H if
> necessary is the best, because the compiler otherwise fails to pick up
> definitions such as PATH_MAX from libc's <limits.h>.  ICC supplies its
> own <limits.h> that boils down to
> 
> #ifndef __INTEL_LIMITS_H
> #define __INTEL_LIMITS_H 1
> 
> #define _GCC_LIMITS_H_
> 
> #ifndef _LIBC_LIMITS_H_
>  #include_next <limits.h>
> #endif
> 
> /* ... */
> 
> #else
> #include_next <limits.h>
> #endif /* __INTEL_LIMITS_H */
> 
> 
> GCC's <limits.h> in turn chains to libc's <limits.h> only if
> _GCC_NEXT_LIMITS_H is defined, which evidently fails to occur by
> default (arguably a compiler bug):
> 

I'm hoping to release 2.64 soon; is any of this a show-stopper that should
be resolved prior to the stable release?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoqn7sACgkQ84KuGfSFAYCX2gCff01u+Nsnl8o6arDNsVSduXLr
HskAoKWl3mSuzLI4kDW9v7wD7KCj+Nwg
=0Mwp
-----END PGP SIGNATURE-----