gnupic: Compiling gpsim-0.20.14 under Mandrake 9.0
Subject:
Re: Compiling gpsim-0.20.14 under Mandrake 9.0
From:
"Mark J. Dulcey" ####@####.####
Date:
14 Oct 2002 21:50:52 -0000
Message-Id: <3DAB3B05.6020603@buttery.org>
Scott Dattalo wrote:
> On Mon, 14 Oct 2002, Andy wrote:
>
>
>>Hi
>>
>>I switched to Mandrake 9.0 a couple of weeks ago and find that I cannot
>>compile gpsim-0.20.14 under it. Compiled fine under 8.2. Below is a snippet
>>of the error output from make:
>>
>>In file included from parse.yy:32:
>>command.h:55: 'string' is used as a type, but is not defined as a type.
>>command.h:56: 'string' is used as a type, but is not defined as a type.
>>command.h:82: parse error before `&' token
>>make[2]: *** [parse.lo] Error 1
>>make[2]: Leaving directory `/usr/local/src/gpsim-0.20.14/cli'
>>make[1]: *** [all-recursive] Error 1
>>make[1]: Leaving directory `/usr/local/src/gpsim-0.20.14'
>>make: *** [all-recursive-am] Error 2
>>
>>OK the error seems blindingly obvious but where do I need to define 'string'
>>as a type for this to work?
>
>
> This sounds like a C++ issue. Have you compiled any other package besides
> gpsim?
Mandrake 9.0 is one of the new GCC 3.2-based distributions; Red Hat 8.0 and SuSE 8.1 are others. The move to GCC 3.2 breaks a number of things in C++.
First, you have to rebuild all C++ binaries; the application binary interface for C++ has changed, and old binaries won't link with the new GCC 3 based libraries that come with the system.
Second, GCC 3 enforces the use of namespaces much more strictly than previous GCC releases did. The quick fix is to add
using namespace std;
to your source files, just after all the #include statements. That brings everything in the std:: namespace into yours, just like GCC 2.9 did. A better long-term fix is to add
using std::string;
(and similar statements for other things from the std:: namespace that you use) to your source files. Alternately, you can change calls; instead of saying "cout << foo;", you can say "std::cout << foo;" in your code.
GCC 3 is a big step forward: better standard compliance, higher quality code, support for new architectures such as Itanium. But there is some pain in converting - and even more if you want to maintain backward compatibility, or if you write code for GCC 3 and then want to backport it to older versions. It mostly hits C++ programmers; the changes for C programmers are much less troublesome.
