Ok, the "reverse experiment" seems to prove that the final linking stage is the one where dynamic_cast problems appear. There seems to be nothing wrong with the object (.o) files and library (.a) files produced by Debian g++ and other tools (ar + ranlib). What I did was that in a Debian machine, I took the v1.00 sources and did export CC=gcc-3.2 export CXX=g++-3.2 ./configure make as usual, and tarred the whole directory. Tested the executable bin/ghemical and noted that it crashes in dyn-cast statements. Then I moved the tar-package to a RedHat9 machine, un-tarred and did ./configure to change the compiler etc settings. Then I removed the executable and just re-linked it using RedHat libs and g++: rm bin/ghemical make The resulting executable, built using Debian-made .o and .a files, worked without a hitch. JII-HAA! :) So, it's either in libraries or in linker. The fact that both g++-3.0 and g++-3.2 has the same behaviour might suggest (but does not prove) that there is a non-functional library that both linkers use? Is there anything else that I could test? Regards, Tommi