To temporarily fix the problem, edit the Makefiles in place:

find . -name "Makefile" | xargs -L 1 perl -pi -e 's/-fno-check-new//g'


to remove the unrecognized option by clang, and build again.

It can be done in configure script, before calling it so option isn't put in Makefiles. A final fix would be to add condition in configure.ac not to have it on OS X.

i'd prefer not changing our gcc options just because clang doesn't support them. You're welcome to supply patches to improve clang building in both configure and cmake (i.e. check if the flag is supported before adding it, i think cmake at least has something similar).

For me it's not a top priority

The boilerplate for this sort of autoconf check is something like:


saved_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="-fno-check-new $CXXFLAGS"
AC_MSG_CHECKING([for -fno-check-new compiler flag])
AC_TRY_COMPILE([], [int main (void) { return 0; }],
  AC_MSG_RESULT([yes]),
  AC_MSG_RESULT([no])
  CXXFLAGS="$saved_CXXFLAGS"
])


Obviously could extract this result into a temp variable first and concat into the larger CXXFLAGS assignments in the relevant case/esac sections rather than having the test itself leave the result in the live variable.

(In reply to comment #4)

...which is why one should test things first. Either that AC_TRY_COMPILE needs to be fixed to use C++ or the flag being tested needs to go via CFLAGS for purposes of the test itself that otherwise is running as plain C.

The following seems to work:

AC_MSG_CHECKING([for -fno-check-new compiler flag])
AC_LANG_PUSH([C++])
saved_CXXFLAGS=$CXXFLAGS
CXXFLAGS="-fno-check-new $CXXFLAGS"
AC_TRY_COMPILE([], [],
  AC_MSG_RESULT([yes]),
  AC_MSG_RESULT([no])
)
CXXFLAGS=$saved_CXXFLAGS
AC_LANG_POP

I'll be happy to provide a patch against current git, but there are two approaches. Reason I ask is that the flag is only *sometimes* added, via various branches of a case statement beginning at line 814.

1. Do this test (always) and store the result in a temp variable, and then use that result to control whether the flag is propagated in the branches where it was previously hardcoded to add.
2. Do this test and propagate the flag only in the branches where it is currently hardcoded to use.

The tradeoff is that option 1 avoids duplicating the test code itself (less fragile if the case logic changes) but means the test is run even in situations where its results would be ignored. Please let me know which approach you would prefer (or some other approach altogether).

Less code is always better, don't care if the autoconf step is a bit slower, is not something that is time critical.

Created attachment 108810 [details] [review]
Only consider adding -fno-check-new if compiler supports it

On my OS X 10.8 with clang, this correctly recognizes that it is not supported and does not propagate it (even when propagating the other flags). If I hack this test to use a different flag that is supported, it correctly recognizes that and propagates it. But I don't have an actual machine that does support this flag to do a direct test that the patch behaves there.

Do we really need this? I've tested clang 3.5 and clang 3.6 and both seem to support the flag, is people using older clangs?

> Do we really need this? I've tested clang 3.5 and clang 3.6 and both seem to
> support the flag, is people using older clangs?

Yes, FreeBSD 10.1 uses clang 3.4.1 as the system compiler.

Pushed.