This is the mail archive of the
mailing list for the GCC project.
Re: string.h and std_cstring.h
- From: jtc at acorntoolworks dot com (J.T. Conklin)
- To: "Graeme Peterson" <gp at qnx dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: 05 Aug 2002 06:22:33 -0700
- Subject: Re: string.h and std_cstring.h
- References: <200208022109.VAA540565538@node128.ott.qnx.com>
- Reply-to: jtc at acorntoolworks dot com
"Graeme Peterson" <email@example.com> writes:
> I am working on the QNX i386-nto support in gcc again.
> The current stumbling block is that our string.h declares
> memchr, strchr, strpbrk, strrchr, and strstr as inline.
> So does libstdc++-v3/include/c_std/std_cstring.h. This
> cause libstdc++ to not build.
> Comments? Am I missing something?
The QNX libstdc++ port requires it be configured with --enable-
cheaders=c. There are a couple of problems with this approach
that I haven't yet been able to resolve, but it is good enough
for us to use our GCC port to generate code for our product.
The first problem is that including <cstdio>, etc. will cause the
functions to be exported intro the standard namespace because the
"c" headers don't have the magic necessary to avoid exporting them
(on QNX undefining _STD_USING, including the header, and then
redefining _STD_USING). I've been told that Solaris uses a similar
mechanism, so I've been hoping to get some free time so I can come
up with a solution that will work for both.
The second problem is minor in comparison. The "c_std" headers
contain macros that use gcc' __builtin_foo() intrinsics. Since this
is just performance rather than correctness, it's probably best that
these be added to the base OS headers. I don't think that using
fixincludes is appropriate for this purpose.
If you check in the libstdc++ mailing list archives, you'll see all
the discussion wrt. the QNX port when I was contributing it.