> 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 ([EMAIL PROTECTED])
