Re: [bug-gnulib] Symbol availability in C, C++

[Bruno Haible]

Albert Chin wrote on 2005-11-26:
> It's not necessarily safe to assume a system variable/function/header,
> if available to the C compiler, is available to the C++ compiler. This
> is even in the case the same vendor provides the C and C++ compiler.
> For example:
>   1. On Tru64 UNIX 5.1, <stdint.h> is available to the C compiler,
>      but not the C++ compiler.
>      $ cat test.c
> #include <stdint.h>
>      $ cc -c test.c
>      $ cp test.c test.cc
>      $ cxx -c test.cc
> cxx: Error: test.cc, line 1: could not open source file "stdint.h"
> #include <stdint.h>
> -------------------^
> cxx: Info: 1 error detected in the compilation of "test.cc".

Ouch. Then you will have to perform the autoconf test with the C++ compiler
instead of the C compiler. Use   AC_LANG_PUSH([C++])  before the test, and
AC_LANG_POP([C++])  after the test.

>   2. On HP-UX 11.23/IA, <wchar.h> will bring in mbstate_t for the
>      C++ compiler, but not the C89 compiler.
>      $ cat test.c
> #include <wchar.h>
>      $ cc -E test.c | grep mbstate_t

This is invalid, no? I have the following section in the INSTALL file
of GNU gettext:

---------------------------------------------------------------------------
Particular Systems
==================

   On HP-UX, the default C compiler is not ANSI C compatible.  If GNU CC
is not installed, it is recommended to use the following options in order
to use an ANSI C compiler:

     env CC="cc -Ae" ./configure
---------------------------------------------------------------------------

> How do we solve this? We've currently solved it by implementing
> separate defines depending on the language. As an example, I've
> attached our patched mbstate_t.m4 below. We've done something similar
> for inttypes_h.m4, stdint_h.m4, and uintmax_t.m4. Is this the correct
> approach? Ideally, we should autodetect AC_PROG_CXX and build with the
> C++ compiler only if AC_PROG_CXX has been called (AC_PROVIDE_IFELSE?).

I'd suggest to use the stricter among the used language processors. In
this case it's probably C++ for most tests.

No need to change the .m4 files. Adding a pair of
   AC_LANG_PUSH([C++])
and
   AC_LANG_POP([C++])
in configure.ac should be enough.

Bruno