Re: Need assistance QNX libc/GNU libstdc++ header file conflicts

[jtc at acorntoolworks dot com (J.T. Conklin)]

jtc@acorntoolworks.com (J.T. Conklin) writes:
> The same problem occurs for strchr, strrchr, strpbrk, abs, acos, tanhl, 
> etc.  I don't know whether the Dinkum/QNX or the stdc++ headers are wrong, 
> or if it's simply a matter of the two being incompatible with each other.
> For the time being, I'm wrapping such definitions with ifndef __QNX__,
> but I know is clearly not the right way...

After going down this path a bit further, I realized that adding all
these conditionals were making c_std headers look very much like the 
c headers.  Compiling with --enable-cheaders=c allowed me to make a 
lot of progress.  Is it permissable to have a target config change 
the --enable-cheaders default from std to c?

The only thing I'll be missing is magic to prevent the functions from
being exported (with "using std::foo;").  The QNX headers use a idiom
in <cfoo> like:
        #ifdef _STD_USING
        # undef _STD_USING
        # include <foo.h>
        # define _STD_USING
        #else
        # include <foo.h>
        #endif

And in <foo.h>:
        #ifdef _STD_USING
        using std::foo;
        using std::bar;
        using std::quux;
        ...
        #endif

_STD_USING is defined by sys/cdefs.h, which is included pretty much by
every header file.

While getting standard-conformance is a desired, getting a working
toolchain for our developers is more pressing, so I'll be puting this
on the back burner for the moment.
        

I have some other configuration questions.  Is there any reason to add
an qnx*) entry to configure.target to set os_include_dir?  It appears
the configure script unconditionally overrides it.

Will I need a separate libstdc++ copyright assignment to contribute
the QNX target, or will my existing gcc assignment be acceptable?

        --jtc

-- 
J.T. Conklin