[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_LANG_FUNC_LINK_TRY(C): stub detection fails with ICC 10.1
From: |
Aaron Ucko |
Subject: |
Re: AC_LANG_FUNC_LINK_TRY(C): stub detection fails with ICC 10.1 |
Date: |
Sat, 06 Jun 2009 20:51:57 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (darwin) |
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