This is the mail archive of the
mailing list for the libstdc++ project.
Re: Need assistance QNX libc/GNU libstdc++ header file conflicts
- From: jtc at acorntoolworks dot com (J.T. Conklin)
- To: libstdc++ at gcc dot gnu dot org
- Date: 20 May 2002 11:13:20 -0700
- Subject: Re: Need assistance QNX libc/GNU libstdc++ header file conflicts
- References: <email@example.com>
- Reply-to: jtc at acorntoolworks dot com
firstname.lastname@example.org (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:
# undef _STD_USING
# include <foo.h>
# define _STD_USING
# include <foo.h>
And in <foo.h>:
_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?