[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HP C++ and gnulib string.h
From: |
Albert Chin |
Subject: |
Re: HP C++ and gnulib string.h |
Date: |
Wed, 5 Sep 2007 12:33:17 -0500 |
User-agent: |
Mutt/1.5.6i |
> 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)