What is the easiest way to downgrade g++?
I am running SuSE Linux 10.0 which ships with g++ 4.0.2. However, several of my programs that were working fine under 3.3.5 will not build under 4.0.2. I consistently get the following errors: /usr/include/c++/4.0.2/bits/sstream.tcc:112: error: expected unqualified-id before '(' token /usr/include/c++/4.0.2/bits/sstream.tcc:114: error: expected unqualified-id before '(' token I would like to downgrade my c++ environment to 3.3.x so I can get back to where I was (working!). What is the most direct/quickest way to get back where I was? I noticed that 3.3.x is not on the DVD. Thanks, Darrell
On Friday 24 March 2006 4:58 pm, Darrell Cormier wrote:
I am running SuSE Linux 10.0 which ships with g++ 4.0.2. However, several of my programs that were working fine under 3.3.5 will not build under 4.0.2. I consistently get the following errors:
/usr/include/c++/4.0.2/bits/sstream.tcc:112: error: expected unqualified-id before '(' token /usr/include/c++/4.0.2/bits/sstream.tcc:114: error: expected unqualified-id before '(' token
I would like to downgrade my c++ environment to 3.3.x so I can get back to where I was (working!). What is the most direct/quickest way to get back where I was? I noticed that 3.3.x is not on the DVD. You should probably go to the FSF to get it, and install it along with 4.0.2. http://gcc.gnu.org/ You can have multiple compilers on the system. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Friday 24 March 2006 22:58, Darrell Cormier wrote:
I am running SuSE Linux 10.0 which ships with g++ 4.0.2. However, several of my programs that were working fine under 3.3.5 will not build under 4.0.2. I consistently get the following errors:
/usr/include/c++/4.0.2/bits/sstream.tcc:112: error: expected unqualified-id before '(' token /usr/include/c++/4.0.2/bits/sstream.tcc:114: error: expected unqualified-id before '(' token
I would like to downgrade my c++ environment to 3.3.x so I can get back to where I was (working!). What is the most direct/quickest way to get back where I was? I noticed that 3.3.x is not on the DVD.
This happens at regular intervals and is not related to any particular version of g++. If you google for the error message you'll see it reported against multiple versions of it. The problem doesn't even seem to be in gcc, it seems that something #define:s min and max before sstream gets parsed, so the std::min and std::max lines break How about saying what it is you're trying to compile, that's where the fix should be (whatever it is, it shouldn't be #defining those things) -- Certified: Yes. Certifiable: of course! jabber ID: anders@rydsbo.net
On Friday 24 March 2006 16:17, Anders Johansson wrote:
On Friday 24 March 2006 22:58, Darrell Cormier wrote:
I am running SuSE Linux 10.0 which ships with g++ 4.0.2. However, several of my programs that were working fine under 3.3.5 will not build under 4.0.2. I consistently get the following errors:
<snip>
This happens at regular intervals and is not related to any particular version of g++. If you google for the error message you'll see it reported against multiple versions of it.
The problem doesn't even seem to be in gcc, it seems that something #define:s min and max before sstream gets parsed, so the std::min and std::max lines break
How about saying what it is you're trying to compile, that's where the fix should be (whatever it is, it shouldn't be #defining those things)
-- Certified: Yes. Certifiable: of course! jabber ID: anders@rydsbo.net
Hmmm. Interesting question. I am building projects that have several libraries and header files that have been built by my counter part in another part of the world. Unfortunately he is on vacation for some time yet so have not had the opportunity to get his opinion. If I just compile my development it works fine. It is not until the build that I have problems. Everything works in earlier versions of g++ (3.3.5 and 3.3.6 at least). I will have to try to pinpoint which file is giving me grief. Thanks, Darrell
On Friday 24 March 2006 23:42, Darrell Cormier wrote:
problems. Everything works in earlier versions of g++ (3.3.5 and 3.3.6 at least).
Honestly, I doubt it. I suspect if you were to install these earlier versions you would get the same error. Something else you are #including is #defining min and max, and that is causing the breakage. I don't think it's the upgrade of gcc that breaks, it's the upgrade of something else -- Certified: Yes. Certifiable: of course! jabber ID: anders@rydsbo.net
On Friday 24 March 2006 16:49, Anders Johansson wrote:
On Friday 24 March 2006 23:42, Darrell Cormier wrote:
problems. Everything works in earlier versions of g++ (3.3.5 and 3.3.6 at least).
Honestly, I doubt it. I suspect if you were to install these earlier versions you would get the same error. Something else you are #including is #defining min and max, and that is causing the breakage. I don't think it's the upgrade of gcc that breaks, it's the upgrade of something else
-- Certified: Yes. Certifiable: of course! jabber ID: anders@rydsbo.net
Actually, the only test I have made is on an Ubuntu system that happened to have the 3.3.6 installed along with the 4.0.2. With 4.0.2 I get the errors, but when I switch to 3.3.6 with the exact same kdevelop projects the build works fine. DC
On Friday 24 March 2006 23:54, Darrell Cormier wrote:
Actually, the only test I have made is on an Ubuntu system that happened to have the 3.3.6 installed along with the 4.0.2. With 4.0.2 I get the errors, but when I switch to 3.3.6 with the exact same kdevelop projects the build works fine.
ok, then maybe something is testing for the gcc version, and doesn't recognise versions 4.x.x, and does something silly, I don't know. The point is that if you compile the project with the -save-temps flag to leave intermediate files around, you will see that the std::min( and std::max( from those two lines have been turned into something completely different. And I doubt it's gcc's fault. The quickie fix for you might be to get the older compiler and keep using it, but if it were me doing the development, I would prefer fixing the real error, so I wouldn't have to stay on older versions indefinitely. On the other hand, if your counterpart has built binary libraries that you are trying to link to, and those libraries were written in c++, then I don't think you have much of a choice, you have to use the same version of g++ as he did. The gcc c++ project changes ABI quite frequently, in my experience -- Certified: Yes. Certifiable: of course! jabber ID: anders@rydsbo.net
On Friday 24 March 2006 23:42, Darrell Cormier wrote:
Hmmm. Interesting question. I am building projects that have several libraries and header files that have been built by my counter part in another part of the world. Unfortunately he is on vacation for some time yet so have not had the opportunity to get his opinion. If I just compile my development it works fine. It is not until the build that I have problems. Everything works in earlier versions of g++ (3.3.5 and 3.3.6 at least). I will have to try to pinpoint which file is giving me grief.
btw, quick fix/workaround: what are you including that pulls in sstream.tcc? <complex>? Whatever it is, put #undef min #undef max immediately before the #include, and you will at least not see these errors again. (And perhaps with a little luck whatever it is that #defines them will throw an error because of it, so you can see what it is) -- Certified: Yes. Certifiable: of course! jabber ID: anders@rydsbo.net
On Friday 24 March 2006 16:57, Anders Johansson wrote:
On Friday 24 March 2006 23:42, Darrell Cormier wrote:
btw, quick fix/workaround: what are you including that pulls in sstream.tcc? <complex>? Whatever it is, put
#undef min #undef max
immediately before the #include, and you will at least not see these errors again. (And perhaps with a little luck whatever it is that #defines them will throw an error because of it, so you can see what it is)
-- Certified: Yes. Certifiable: of course! jabber ID: anders@rydsbo.net
Thanks Anders, When I make the following change to a header file: #undef min #undef max #include <sstream> Then my build messages change from: /usr/include/c++/4.0.2/bits/sstream.tcc: In member function 'virtual typename std::basic_stringbuf<_CharT, _Traits, _Alloc>::int_type std::basic_stringbuf<_CharT, _Traits, _Alloc>::overflow(typename _Traits::int_type)': /usr/include/c++/4.0.2/bits/sstream.tcc:112: error: expected unqualified-id before '(' token /usr/include/c++/4.0.2/bits/sstream.tcc:114: error: expected unqualified-id before '(' token gmake[2]: *** [wmap_search_server.o] Error 1 To: linking wmap_search (g++) /home/dcormier/develop/lubbock_services/lib/libCfunc.a(dir_files.o): In function `char* std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_construct<char*>(char*, char*, std::allocator<char> const&, std::forward_iterator_tag)': dir_files.C: (.gnu.linkonce.t._ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag+0x27): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_create(unsigned int, std::allocator<char> const&)' dir_files.C: (.gnu.linkonce.t._ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag+0x58): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_empty_rep_storage' dir_files.C: (.gnu.linkonce.t._ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag+0x5e): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_empty_rep_storage' /home/dcormier/develop/lubbock_services/lib/libtcp.a(tcpServer.o): In function `tcpServer::signal_action(int)': tcpServer.C:(.text+0x43c): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_empty_rep_storage' tcpServer.C:(.text+0x443): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_empty_rep_storage' tcpServer.C:(.text+0x468): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_empty_rep_storage' /home/dcormier/develop/lubbock_services/lib/libtcp.a(tcpServer.o):tcpServer.C: (.text+0x470): more undefined references to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_empty_rep_storage' follow collect2: ld returned 1 exit status gmake[2]: *** [wmap_search] Error 1 gmake[2]: Target `all' not remade because of errors. Not sure what to do with that information yet, but it is a start. Thanks, DC
participants (3)
-
Anders Johansson -
Darrell Cormier -
Jerry Feldman