Re: HP C++ and gnulib string.h

[Albert Chin]

> On Sat, 1 Sep 2007 22:15:58 +0200, Bruno Haible wrote:
> > 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.

Possibly. lftp-3.5.11, an ftp client which is more a mix of C/C++,
exposes more differences (cf.
http://lists.gnu.org/archive/html/bug-gnulib/2005-11/msg00085.html).

> 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?

This does not work. The error occurs in the same place. The resulting
config.status between CC=cc and CC=aCC shows now substantive
difference.

> b) In configure.ac change the gl_INIT invocation into
> 
>    AC_LANG_PUSH([C++])
>    gl_INIT
>    AC_LANG_POP([C++])
> 
>    Does this work?

No:
  /opt/fsw/bash30/bin/bash ../libtool --tag=CC --mode=compile cc 
-DHAVE_CONFIG_H -I. -I. -I.. -I../poppler     -z +O2 +Ofltacc +Olit=all 
+Oentrysched +Odataprefetch +Onolimit -c -o printf-args.lo printf-args.c
   cc -DHAVE_CONFIG_H -I. -I. -I.. -I../poppler -z +O2 +Ofltacc +Olit=all 
+Oentrysched +Odataprefetch +Onolimit -c printf-args.c  +Z -DPIC -o 
.libs/printf-args.o
cpp: "///opt/aCC/include/stdio.h", line 4: error 4036: Can't open include file 
'cstdio'.

The problem is that gnulib's generated stdio.h has:
  #include "///opt/aCC/include/stdio.h"
rather than the expected:
  #include "///usr/include/stdio.h"

> 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?

I haven't tried but I'm sure this would work. But, this is really
ugly. I think "./configure && make && make install" should just work.
The fundamental problem is mixing a C/C++ project with gnulib when the
C/C++ compilers exhibit different behavior. I think gnulib should
accommodate this. But, I think it should be supported on a
case-by-case basis. That is, if someone reports a problem building
some mixed C/C++ project against gnulib, we fix that part of gnulib
rather than some major overhaul. This would be the least intrusive and
require the least amount of work.

-- 
albert chin (address@hidden)