[sr #110532] AC_CHECK_LIB no longer works with a C++ compiler

[Vincent Lefèvre]

Follow-up Comment #2, sr #110532 (project autoconf):

MPFR is written in C, and it is generally compiled with a C compiler, so that
we expect the compiler to be given by $CC. This means that we need AC_LANG(C),
not AC_LANG(C++).

But we also allow C++ compilers (some compilers seem to support only C++, and
testing with a C++ compiler also allows us to detect some issues with the
header files). And since the compiler is given by $CC, g++ (for instance) is
used via CC=g++.

___

Reply to this item at:

  

___
  Message posté via Savannah
  https://savannah.gnu.org/

[sr #110530] Missing #include in AC_FUNC_MEMCMP

[Zack Weinberg]

Follow-up Comment #2, sr #110530 (project autoconf):

1. We currently don't support *any* use of -Werror or -Werror=whatever in
configure scripts.  There are lots and lots of places where autoconf's test
programs trigger warnings, especially with newer compilers. We *want* to fix
all of those eventually but we have *no* developers right now, so "eventually"
might be a very long time.

The recommended way to use -Werror with autotools is with an AC_ARG_ENABLE
construct that *optionally* adds -Werror to a dedicated AC_SUBST variable that
is then added to AM_CFLAGS in Makefile.am (or equivalent if you're not using
automake).

2. That said, HAVE_STRING_H should have been defined automatically.  Could you
please cut down dfu-programmer's configure.ac to the smallest thing you can
manage that still reproduces the issue, and attach that file here?  Please
also make it self-contained -- inline any definitions from aclocal.m4 that are
needed.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110532] AC_CHECK_LIB no longer works with a C++ compiler

[Zack Weinberg]

Follow-up Comment #1, sr #110532 (project autoconf):

This (and the matching set of changes to AC_LANG_CALL(C++)) is in fact the
main thing I was thinking of when I wrote in the 2.70 release notes that
"setting CC to a C++ compiler is no longer supported."

That said, I'm not rejecting your patch out of hand, but I would like more
detail on exactly what you did that caused code generated by AC_LANG_CALL(C)
to get processed by a C++ compiler.  If, for instance, there is some obstacle
you're encountering that prevents you from using AC_LANG(C++) in all the right
places, perhaps we should fix _that_ instead.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/