The strstream.h has the wrong name: 'strstream' ll /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/include/g++-v3/backward/ ... -rw-r--r-- 1 root root 1545 2003-10-12 02:10 stream.h -rw-r--r-- 1 root root 5671 2003-10-12 02:10 strstream -rw-r--r-- 1 root root 3023 2003-10-12 02:10 tempbuf.h ... Please rename it to strstream.h Reproducible: Always Steps to Reproduce: Portage 2.0.49-r7 (default-x86-1.4, gcc-3.3.1, glibc-2.2.5-r4,2.3.2-r1, 2.4.20-gentoo-r1-2)
This is correct behaviour, it's there to correct "#include <strstream>".
As per Comment #1, this is apparently correct behaviour on gcc's part. I can confirm this is the same in gcc-3.3.2. If it is a bug, then this would need to be filed with the GCC people directly. Resolving as INVALID.
There is no strstream(.h) in C++ only <sstream> This is a bug because the GCC warning cause by this include file say: " ...<sstream> instead of the deprecated header <strstream.h>..." Take a look at gcc-3.2.3 and before that -- From my GCC-3.2.3-r -rw-r--r-- 1 root root 5671 2003-10-12 09:35 strstream -rw-r--r-- 1 root root 1573 2003-10-12 09:35 strstream.h -rw-r--r-- 1 root root 3023 2003-10-12 09:35 tempbuf.h And the code of part of strstream.h #ifndef _CPP_BACKWARD_STRSTREAM_H #define _CPP_BACKWARD_STRSTREAM_H 1 #include "strstream" using std::strstreambuf; using std::istrstream; using std::ostrstream; using std::strstream; #endif Please add the missing strstream.h from gcc3.2.3 line.
This breaks a lot of old C++ code.
It only breaks code that isn't ISO C++, and g++ is an ISO C++ compiler. I don't see how this is anything other than expected behaviour?
Then please removed the include/g++-v3/backward files so that we are forced to use ISO C++ :-) But not all (old) C++ compiler support ISO C++ that is why we need the backward compatibility header files because pre-ISO C++ code can be compile by almost all C++ compiler.
I really don't think this is something we in Gentoo can effectively deal with. Since just about every new gcc exhibits this behavior, that would be alot of patching to simply support "old" c++ code. If you feel strongly about this, I highly advise filing a bug of this nature on GCC's bugzilla and attempt to get it worked out upstream with the GCC people. Package developers need to get up to spec honestly. GCC is emerging as one of the most widely used compilers out there, so packages still using deprecated headers are likely going to fail. Also including the strstream.h file from gcc-3.2.3 into gcc-3.3.x is guaranteed to break things. Much has changed between those two branches, and we are even looking at gcc-3.4 on the horizon in a few months.
I found a bug 9925 in GCC about strstream(.h) where I added the information. I have also added it as bug in GCC: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12766 I will report back when/if it is fixed in GCC. I was testing gcc-3.4 with profiledbootstrap :-) (GCC CVS) when I found that the file was missing.
It was rejected by GCC becuase in it not strict ISO C++. But in the gentoo linux HOWTO: /usr/share/doc/HOWTO/text/C++Programming-HOWTO.gz [ebuild R ] app-doc/howto-text-20031006 It say use strstream.h. ----------------------------- section 9.5 --------------------- 9.5. Forget C ....Instead of this: #include <iostream.h> #include <stdio.h> /* . . . */ char myaString[100]; sprintf(myaString, "%s, %s %c", myaLname, myaFname, *myaMname); cout << myaString << '\n'; Try This: #include <iostream.h> #include <strstream.h> /* . . . */ ostrstream ost; ost << myaLname << ", " << myaFname << " " << *myaMname; ost.put(0); //null terminate the string cout cout << ost.str() << '\n'; ----
Then the howto is broken, and should be fixed. :-) (In fact it's been "removed for review".)
Okay, since the GCC people even rejected the change, I'm going to close this bug out. This is just a necessary change in the continued evolution of GCC. If you come across any packages in gentoo that references the older strstream.h file, please file a bug and assign it to gcc-porting. It's why this team exists. It's better to change the packages themselves, rather than attempt to re-introduce deprecated behaviour back into gcc, which is bound to be a nightmare to even consider attempting.
