Hello Albert,
> On 11.x/PA,
> the HP C++ compiler does not support #include_next. So, we get
> #include "///usr/include/string.h". This fails to include the
> C++-specific <string.h> and thus some functions like strchr() don't
> get defined, leading to compile failures. When you #include <string.h>
> in a C++ program, /opt/aCC/include/string.h is included first, which
> then includes /usr/include/string.h (via <cstring>). The reverse
> doesn't work.
>
> So, do we need to compensate for this. I hacked up something to work
> around this and have attached it.
Thanks for the report and patch.
I'm worried that more differences between the C and C++ compilers are
found. It may be not only the location of <string.h>, but also
HAVE_DECL_STRRCHR, the presence of an uint32_t type, etc. What's the
result of trying three alternative approaches?
a) Instead of "CC=cc CXX=aCC ./configure", use
"CC=aCC CXX=aCC ./configure". This works with g++. Does it also work
with aCC?
b) In configure.ac change the gl_INIT invocation into
AC_LANG_PUSH([C++])
gl_INIT
AC_LANG_POP([C++])
Does this work?
c) A radically different way of using gnulib: Create a gnulib testdir
with all POSIX functions that you find useful (snprintf-posix etc.).
Configure it once with C and once with C++, like this:
$ GNULIBDIR=`pwd`
$ mkdir build-cc; CC=cc ../configure; make; cd ..
$ mkdir build-c++; CC=aCC ../configure; make; cd ..
Then go back to your package and configure it with
CC="cc -I$GNULIBDIR/build-cc/lib" \
CXX="aCC -I$GNULIBDIR/build-c++/lib" \
LDFLAGS="$GNULIBDIR/build-cc/lib/libgnu.a
$GNULIBDIR/build-c++/lib/libgnu.a" \
./configure
Does this work?
Bruno
