This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.0 cannot compile pooma
- To: "Zack Weinberg" <zackw at stanford dot edu>
- Subject: Re: gcc 3.0 cannot compile pooma
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- Date: 06 Jun 2001 07:12:12 +0200
- Cc: Gabriel Dos Reis <gdr at codesourcery dot com>, Jeffrey Oldham <oldham at codesourcery dot com>, Peter Schmid <schmid at snake dot iap dot physik dot tu-darmstadt dot de>, gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, pedwards at disaster dot jaj dot com
- Organization: CodeSourcery, LLC
- References: <20010605215602.Z979@stanford.edu>
"Zack Weinberg" <zackw@stanford.edu> writes:
| On Wed, Jun 06, 2001 at 06:28:44AM +0200, Gabriel Dos Reis wrote:
| > Jeffrey Oldham <oldham@codesourcery.com> writes:
| >
| > | 2) Create a separate <string.h> file.
| > |
| > | <string.h> = <cstring>
| > | using std::size_t;
| > | using std::memcpy;
| > | // ...
| > |
| > | <cstring> = namespace std {
| > | #include "/usr/include/string.h" /* fully-qualified path */
| > | }
| > |
| > | <cstring> must use a fully-qualified path rather than <string.h> to
| > | avoid infinite recursion.
| > |
| > | The latter comes closer to the standard but requires some additional
| > | work during creation to resolve the fully-qualified path.
| >
| > On some plateforms (Robert Lipe could provide data) the actual paths
| > depends on the `-ansi -pedantic' or something like that.
| >
| > Creating <string.h> in terms of <cstring> is what we're supposed to do
| > but...
|
| This is exactly what #include_next is for.
Do you mean for the solving
pathnames-which-depend-on-conformance-flags problem?
| But I kind-of think that there's more to it than that. Isn't this
| what the c_shadow headers are supposed to be doing, and they don't
| work right at the moment?
Exactly!
-- Gaby