./libstdc++-v3/include/bits/stl_alloc.h : Incompatibility between g++ 3.3 and g++ 3.2?

[Martin Beaudoin]

Hello,

I am experiencing some STL compatibility problems between  

g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

and

g++ (GCC) 3.3 20030226 (prerelease) (SuSE Linux 8.2)


I have a library compiled with g++ version 3.3 on Suse 8.2. The library 
is making heavy use of STL.

When I link this library with a program compiled with gcc 3.2 on RedHat 
8.0,  the linker complains about the  

undefined reference to `std::__default_alloc_template<(bool)1, 
(int)0>::_S_force_new'

Indeed, S_force_new is defined in 
./libstdc++-v3/include/bits/stl_alloc.h for g++ 3.3, but not for g++ 3.2.

But when I look at the online  CVS archive (savannah.gnu.org using 
viewcvs, or gcc.gnu.org using cvsweb), I see that the file 
./libstdc++-v3/include/bits/stl_alloc.h is in the CVS Attic for both 
those versions of gcc.  

So my understanding is that stl_alloc.h was not supposed to be present 
for neither g++ 3.3 and g++ 3.2.

But doing a cvs checkout for both these versions of g++ (tag: 
gcc_3_3_release and gcc_3_2_release, and even tag = gcc_3_3_1_release), 
gives me a ./libstdc++-v3/include/bits/stl_alloc.h file, and some other 
files under ./libstdc++-v3/include/bits (stl_tree.h) are still using 
this file. But stl_alloc.h is in the Attic for those versions....

Only the latest version of gcc seems have gotten rid of 
./libstdc++-v3/include/bits/stl_alloc.h

So, is this a known problem? I can't find anyting on the mailing lists 
about STL incompatibilities between g++ 3.2 and g++ 3.3.

Did someone forgot to to commit the removal of stl_alloc.h for those 
versions? I would like to understand what is happening here on the CVS side.


Now, as for my incompatibilitiy problem (stl_alloc.h is not downward 
compatible from g++ 3.3 to g++ 3.2), the only solution I can see is that 
I need to standardize my development Linux stations over one and only 
one g++ compiler version. 

I would have expected this for major differences in version of g++; I 
expect incompatibilities between gcc 3.x and gcc 2.x., and I would not 
mind upgrading to a newer version in such situations.

But STL incompatibilities between 3.2 and 3.3, I would not have expected 
this.

Any advice or comments on those issues are more than welcomed.

--
Martin Beaudoin
IREQ