Re: HP C++ and gnulib string.h

[Bruno Haible]

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