I suppose this might relate to how Eric H? was "complaining" about
C++ being "hard to compile".
I use a solaris 2.8 box at a virginia.edu address, which was recently
hacked. It took the SAs about a week to regen everything and when they had
finished, I couldn't compile g++ programs that referenced the STL map
class. A simple program including <map> generates lots of link errors.
Here is one of the link errors:
map.o(.gnu.linkonce.t._ZSt18_Rb_tree_rebalancePSt18_Rb_tree_node_baseRS0_+0x198):
undefined reference to `std::_S_rb_tree_red'
Now before the hack, g++ was fine. I don't know exactly what version of
libstdc++ was installed (before) or if the g++ version was changed. But
currently, these are the versions: libstdc++ (3.0.97), gcc (3.0.4)
I did some grepping around and it appears in versions before and after
3.0.97 that std::_S_rb_tree_red was declared in stl_tree.h and defined
there as well. In the current version, it is referenced as extern in
stl_tree.h and defined in an "instantiation" file:
libstdc++-v3/src/stl-inst.cc.
Here is the relevent extern reference from stl_tree.h:
namespace std
{
typedef bool _Rb_tree_Color_type;
extern const _Rb_tree_Color_type _S_rb_tree_red; // false
extern const _Rb_tree_Color_type _S_rb_tree_black; // true
...
}
Here are the contents of stl-inst.cc:
// Explicit instantiation file.
// ISO C++ 14882:
//
#include <bits/c++config.h>
#include <memory>
#include <vector>
#include <ostream>
#include <map>
namespace std
{
const int __stl_threshold = 16;
const int __stl_chunk_size = 7;
const int __WORD_BIT = int(CHAR_BIT*sizeof(unsigned int));
const _Rb_tree_Color_type _S_rb_tree_red = false;
const _Rb_tree_Color_type _S_rb_tree_black = true;
template class __malloc_alloc_template<0>;
#ifndef __USE_MALLOC
template class __default_alloc_template<true, 0>;
#endif
template
void
vector<unsigned int>::
_M_insert_aux(vector<unsigned int>::iterator, unsigned int const &);
} // namespace std
Clearly something is going on so that bits in this instantiation file are
not getting included.
My question is two-fold:
1) When libstdc++ is installed and built, how and where are these
definitions in the instantiation files integrated into the library? If I
grep the .a and .so files, I can't find any reference to
_Rb_tree_Color_type. Should it be greppable in these libs?
2) How can this be fixed? My thought is just to get the latest version of
libstdc++ and move on. Especially as this "instantiation file" seems
cheesy. But maybe there is a simple solution regarding ld
paths or what not.
Lately, I've been using sun's CC (which has a nice rogue wave STL which I
think i like better than gnu's, but CC takes forever to do builds, so
ultimately i'd rather switch back to g++).
Bill
