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

[Aaron Ucko]

Eric Blake <address@hidden> writes:

> [revisiting an old thread]

Thanks for taking the time to do so!

>> $ /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.

Fair enough; upon consideration, it's not difficult to imagine how
this approach could backfire.

>> $ /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.

Great.  Any chance autoconf could generally arrange if necessary for a
definition of that symbol (either via CPPFLAGS or AC_DEFINE), or would
that be too intrusive?  In-house, we currently hard-code that addition
for ICC 10 and up, but it should be possible to implement a
(mis)feature test by checking whether defining _GCC_NEXT_LIMITS_H is
necessary for #include <limits.h> to yield a definition of PATH_MAX.

> 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.

That was the idea, but the _GCC_NEXT_LIMITS_H approach appears to be
saner, as it gets to the root of the problem.

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

Not necessarily; although I'd appreciate a fix at some point, the
problem is ultimately a issue with a specialized compiler, and
affected users can always work around it by running configure with an
appropriate CPPFLAGS setting.

Thanks!

-- 
Aaron Ucko <ucko at ncbi>, NCBI C++ Toolkit core development group