clang was spewing warnings about the unrecognized -fno-default-inline. (Oddly,
it warns only with -c, not when compiling directly to an executable.) For
completeness we also check -pipe, even though clang is OK with that one.
It should be fine to omit either flag. gcc -fno-default-inline drops the
implicit 'inline' annotation on functions defined inside a class scope, but
'inline' is only a hint anyway. -fno-default-inline does not change linkage.
-pipe is merely a compile speed optimization.
There is no way to make clang's "argument unused" warning fatal.
Ideally the search string would also include 'clang: ' but this output might
depend on clang's argv[0].
Recent ncurses can be configured --with-termlib, which splits out the
terminfo-level functions from libncurses into a separate libtinfo.
This allows us to avoid an unnecessary dependency on libncurses. (We
already avoided this on distributions that link with -Wl,--as-needed.)
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Closes#128 github pull request.
AC_MSG_ERROR inside the variable assignment doesn't work properly. We get
output like
checking for protoc... ./configure: line 4524: is: command not found
no
and then the build continues (and fails) with PROTOC="".
Closes#132 github pull request.
Instead of guessing the right function to use, we malloc() 15 bytes more than
we need, and compute the aligned offset within. The AlignedBuffer class takes
care of passing the original pointer to free().
When cross-compiling for Android, configure (erroneously?) decides we don't
have a GNU-compatible malloc, and tries to
#define malloc rpl_malloc
We don't define rpl_malloc, and it's not clear it would work with the <cstdlib>
C++ header, anyway. See
http://nerdland.net/unstumping-the-internet/malloc-has-not-been-declared/
If we aren't using malloc(0), it should be safe to use malloc without the check.
Keegan McAllister