Eric Blake <[email protected]> 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
