On Tue, Apr 15, 2003 at 12:20:21PM +0300, Tommi Hassinen wrote: > Yesterday and today I installed our RedHat 9 machine, and after testing > both v1.00 and v1.50 versions I can tell that the RedHat 9 compiler gah :( > [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. > has no problems dealing with dynamic_cast<>() statements. The both > versions work fine without any patching (like they are in CVS). I haven't > tried with --enable-mpqc yet but my guess is that it works as well. 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? > 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. > > > OK, I've tried to automakefy libghemical. The appended patch > > Wow! :) Thanks! I haven't had time to look it yet, but I will this week > or the next one, and I'll try to apply automake in the new mopac7 library > as well. I did something like that for mopac7 a while (maybe a year) ago. I can try to dig that up if you want. > This might be a dumb question, but you mentioned that aclocal.m4 is > now obsolete as well. So, how the use of automake will affect the > "custom" settings of the configure-script (for example the detection > of sc-config that we have and which works fine); can we still keep > them as they are now? Custom m4-macros go into acinclude.m4, I put the sc-config stuff in there. Running 'aclocal' then generates aclocal.m4 out of configure.in and acinclude.m4, AFAICT. As always, it's debatable whether the generated aclocal.m4 should be put into CVS or not :) Michael