This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: string.h and std_cstring.h

"Graeme Peterson" <> 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.


J.T. Conklin

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]