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
Original-To:	"'Michael E. Flaster'" <flaster AT qts DOT com>,
	"'GNU-Win32'"
	<gnu-win32 AT cygnus DOT com>
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<char,string_char_traits<char> >' has no member named `npos'

When, in bastring.h, included by bastring.cc there is certainly a member npos of the
class:

template <class charT, class traits = string_char_traits<charT> >
class basic_string
{
 ...
  static const size_type npos = static_cast<size_type>(-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".

- Raw text -