On Fri, 25 Oct 2002, William N Luoma wrote: >I suppose this might relate to how Eric H? was "complaining" about >C++ being "hard to compile".
If so, then that's hardly a C++ language problem. You can't blame a language because some SA didn't install the tools correctly. >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. These versions seem to be the correct compatible versions. Sounds like there was a build problem. Did you SA's build the library or just installed binaries that were downloaded off the net? >Clearly something is going on so that bits in this instantiation file are >not getting included. This is completely a library issue. I don't see why an application have to worry about this. Variables with underscores in them are system variables, and should not be used by applications. So as long as you're not using them, you should be fine. Any problems that result are either installation problems or mismatch in the tools. >1) When libstdc++ is installed and built, how and where are these >definitions in the instantiation files integrated into the library? Does the .cc file get included at the end of the .h file? I noticed older g++ STL libraries do this. >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? Yes, if the libs contain debug information. >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. >From everything you've described, the problem seems to be a mismatch between the library and the header file. Either the library is mis-compiled or the header files are mis-installed. In either case, something got botched during the build and installation procedure. It is also possible that during the 'restoration' process, multiple libstdc++.so files are created on the path. Thus, the wrong one is used. Try compiling your sample code with -v option to g++. This should print out the paths that are used during the build and link phases. This will tell you if the build is using the wrong files. If you send me the output of the compile and link, I can comment whether they are correct. --jc -- Jimen Ching (WH6BRR) [EMAIL PROTECTED] [EMAIL PROTECTED]
