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