gcc 3.0 cannot compile pooma
Jeffrey Oldham
oldham@codesourcery.com
Tue Jun 5 21:14:00 GMT 2001
On Wed, Jun 06, 2001 at 03:36:39AM +0200, Peter Schmid wrote:
>
> gcc version 3.0 20010604 cannot compile pooma-gcc on
> i686-pc-linux-gnu. Compilation of
> Serializers.cmpl.cpp stops with the messages:
> /home/peter/trans/pooma-gcc/src/IO/Serializers.h: In function `int
> streamOut(char*&, const T&) [with T = int]':
> /home/peter/trans/pooma-gcc/src/IO/Serializers.h:133: instantiated from `int serialize(Stream&, const T&) [with Stream = char*, T = int]'
> /home/peter/trans/pooma-gcc/src/IO/Serializers.cmpl.cpp:111: instantiated from here
> /home/peter/trans/pooma-gcc/src/IO/Serializers.h:71: `memcpy' undeclared (first
> use this function)
> /home/peter/trans/pooma-gcc/src/IO/Serializers.h:71: (Each undeclared
> identifier is reported only once for each function it appears in.)
> Command exited with non-zero status 1.
>
> A minimal version of the failing source code is shown below:
>
> #include <string>
> extern "C"{
> #include <string.h>
> }
> int streamStringOut(char*& s){
> int len;
> memcpy((void*)s,(const void*)&len, sizeof(len));;
> return len;
> }
>
> Since the successful compilation of pooma is a milestone for the
> release process of the gcc 3.0 compiler, I believe this problem should
> be fixed as soon as possible.
Yes, I also stumbled across this today. The fundamental problem is
that <cstring> is defined in terms of <string.h>, but <string.h>'s
declaration is included only once. Here are details:
<cstring> internally includes <string.h> but removes all memcpy
references but inserts std::memcpy. Then the program's <string.h>
inclusion inserts no new declarations since it has already been
included.
Surprisingly, the problem disappears if the order of inclusions is
reversed: <string.h> declares memcpy. Then <cstring> includes
<string.h> but no new declarations from it are inserted since it has
already been inserted. <cstring> then declares std::memcpy.
Although programmers are unlikely to include both <cstring> and
<string.h>, the same problem occurs for the more likely <iostream> and
<string.h>.
Two possible solutions include:
1) KCC solves the problem this way:
<cstring> = #include <string.h>
#pragma kai_intrinsic "strlen" strlen
namespace std {
using ::size_t;
using ::memchr;
// ...
}
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.
Are either of these solutions easy enough to be implemented before the
gcc3.0 release?
Thanks,
Jeffrey D. Oldham
oldham@codesourcery.com
More information about the Libstdc++
mailing list