On Tue, 15 Apr 2003, Michael Banck wrote: > > [thassine@shrike thassine]$ g++ --version > > g++ (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) > > Debian ships a 3.2.3-prerelease in unstable right now. Hmm. I just updated my "unstable" and tested; it still has the problem. :( > I've just stumbled over http://bugs.debian.org/188943 ("g++-3.2: code > using dynamic_cast causes segfaults when -fno-rtti is used"), but I guess that > does not apply to use, right? A google search about -fno-rtti suggested that the compiler should prompt an error message when it encounters dynamic_cast<>() statements with -fno-rtti option set. RTTI is required by dynamic_cast<>() statements. > > Mandrake-9.0 ok > > RedHat 8.0 ok > > RedHat 9.0 ok > > Debian "testing" problems > > Debian "unstable" problems > > Does RedHat-8 use g++-3.2 already? I'll try to find the RH-9 Changelog > and see if they perhaps applied some patches to fix this problem. Yes, the following are version info for RedHat8 and Mandrake9 g++: $ g++ --version g++ (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++ --version g++ (GCC) 3.2 (Mandrake Linux 9.0 3.2-1mdk) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Both of the above work, so I think the error has existed already some time in the Debian compilers. I also think that g++-3.0 worked in Debian but I didn't use it much and I guess I haven't used g++-3.1 at all. Hummm... I could in fact install and test them. In "testing" it goes this way: debian "testing" g++-3.0 : does NOT work; has the same problem as g++-3.2!!! debian "testing" g++-3.1 : the packages do not exist??? I double-checked it, but it seems to be true that also g++-3.0 has the dynamic_cast problem. Quite surprising! The bug can be very old then? Or is there a library or other tool (like a linker or something else that handles the binary files) that the both compilers use? Later today I could do an interesting experiment by taking the object files compiled by a RedHat9 compiler and then I link them using Debian tools and libs, let's see what happens. > I did something like that for mopac7 a while (maybe a year) ago. I can > try to dig that up if you want. Thanks. Sure I could use it but don't use many minutes looking for it; I can take the mopac case as an automake-excercise. Regards, Tommi