From: colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp (Colin Peters) Subject: RE: Fixing libiostream.a and _rtti_ 2 Dec 1996 11:08:35 -0800 Sender: daemon AT cygnus DOT com Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <01BBDD1F.A640A640.cygnus.gnu-win32@gbird0.fu.is.saga-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Original-To: "'Michael E. Flaster'" , "'GNU-Win32'" Original-Sender: owner-gnu-win32 AT cygnus DOT com Michael E. Flaster[SMTP:flaster AT qts DOT com] wrote: >Well, I guess I'm going to try to figure out why executables >linked against libstdc++.a in beta 16 will not execute, >or at least figure out a workaround (I only really need >libiostream.a). (BTW, renaming the executable from >a.out to a.exe did not work for me.) > >If I just build libiostream.a, there are many undefined >references to _rtti_ stuff, which I guess stands for >"run time type info". It seems that these references >automatically get inserted by the compiler whenever >there is a virtual destructor in a class. Yes this does seem to be the case, and it's not only a problem for trying to rebuild libiostream.a or other libraries. Almost any non-trivial C++ program, whether it uses the class libraries or not, seems to require libstdc++.a for the rtti stuff. It there a way around this? The documentation is quite tight-lipped (as far as I can find) on rtti. >FYI, I have been able to link an executable against >the iostream lib + stdexcepti.o + exceptioni.o + typeinfoi.o >(+ a stub for Strings) from the stdc++ library. The resulting >executable would still not execute. This seems to imply >that the problem is with either >1. run-time type info >2. Exceptions >3. iostream lib >I'd guess it's 1 or 2, but unfortunately, as I've probably already >demonstrated, I know nothing about them... :-( I actually did almost exactly the same thing, except that I used the GNU source for the iostream and stdc++ libraries (except typeinfoi, which I grabbed from the b14 sources). I also didn't do any stub for strings... but it was an experiment in hacking. Anyway, I managed to get some iostream test executables that ran. Unfortunately some of the tests seemed to fail because of the opening of stdin in text mode... then I had to go on to other things. Currently I've been trying to recompile the b16 source for libstdc++ and got a very strange error in libstdc++/std/bastring.cc line 475, claiming that: /src/libstdc++/std/bastring.cc:475: `class basic_string >' has no member named `npos' When, in bastring.h, included by bastring.cc there is certainly a member npos of the class: template > class basic_string { ... static const size_type npos = static_cast(-1); There do not seem to be any ifdefs or such which would be accidentally commenting this out. I have yet to get really deep into this, but my goal to start with is basically the same as Michael's, get C++ compiles working right, with or without rtti. Of course it would be nice to be able to compile libstdc++ and libiostream too. I suspect the guys at Cygnus have already seen this... is there an easy fix or is it a bug in the C++ parser? Colin. -- Colin Peters - colin AT bird DOT fu DOT is DOT saga-u DOT ac DOT jp -- Saga University Dept. of Information Science -- Fundamentals of Information Science -- http://www.fu.is.saga-u.ac.jp/~colin/home.html - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".