Dear Marc,
Now had the occasion to go through if Gambit termination works on different GCC & G++ versions in OpenBSD 5.2 AMD64 default.
I did not check with the "-latest" aka snapshot OBSD release this time, that could of course provide additional information, though sponaneously I would guess that the issue with eg++ (GCC) 4.7.1 in the default release as described below has the same underlying cause, as the output looks exactly the same.
This test make clear that there is a way to get Gambit going without issues on OBSD, so,
As far as I'm personally concerned this is a solved issue.
For completeness, here are the results:
Correct behavior of Gambit termination for different GCC & G++ versions on OBSD 5.2 AMD64 non-snapshot is as follows:
gcc (GCC) 4.2.1 20070719 (this is the bundled version): Worked. (also ./configure --enable-single-host worked) g++ (GCC) 4.2.1 20070719 (this is the bundled version): Worked.
egcc (GCC) 4.6.3: Worked. eg++ (GCC) 4.6.3: Worked.
egcc (GCC) 4.7.1: Worked. eg++ (GCC) 4.7.1: FAIL
For GCC compilation, ./configure --enable-single-host --enable-debug was used. For G++ compilation, ./configure --enable-single-host --enable-debug --enable-cplusplus was used.
For invocation of the non-default version, CC=/usr/local/bin/egcc or CXX=/usr/local/bin/eg++ respectively was added as prefix to the ./configure command line, in bash.
make clean was used to reset the GCC directory between compilations. The g++ 4.6.3 compilation was also double-checked by also compiling from a fresh Gambit source copy.
Gambit compiled with eg++ (GCC) 4.7.1 produces the following in response to ,q :
Gambit v4.6.6
,q
terminate called after throwing an instance of '___throw_struct' terminate called recursively Abort trap (core dumped)
If I recall right, on the snapshot OBSD AMD64 release, this failure behavior was on both the 4.6 and 4.7 G++, and I did not try the 4.2 release at all due to ./configure's warning about excessive RAM consumption.
The only hint I picked up as regards the source of this issue, is that it might have to do with that 4.7.1 perhaps brings an alternative libstdc++ package (libstdc++ 4.7.1 it's called) while perhaps the other ones don't. I would guess this was not an issue though - it would make no sense for them to publish a problematic package without making the installer print a warning or alike. #openbsd seems to have nothing to say on the topic.
If there would be any checks I could do for completeness at some point, feel free to mention them.
Thanks and with best regards, Mikael
2013/1/3 Mikael mikael.rcv@gmail.com
Hi Marc,
Thank you so much for having a look.
2013/1/3 Marc Feeley feeley@iro.umontreal.ca
I can't reproduce this bug with OpenBSD 5.2 and the g++ 4.2.1 which comes with it. My guess is that the problem is related to a bug in the versions of g++ you have used. Can you install an older g++ and see if that solves the problem? Can you also try to compile using gcc (i.e. don't use --enable-cplusplus)?
Aha funny.
Just for reference, in the test you made, was the OS compiled for the AMD64 architecture?
I did not use 5.2 but "current" a.k.a. "snapshot" for AMD64, as found on http://www.mirrorservice.org/pub/OpenBSD/snapshots/amd64/ . Except for regarding exiting Gambit, this version of the system has shown to perfectly stable in every way I checked, so this is why I was so surprised to see any issue about Gambit's execution on it.
And right, I tried with G++ 4.7.2 and 4.6.3. On your 5.2 installation, installing this would look something like:
PKG_PATH=http://www.mirrorservice.org/pub/OpenBSD/5.2/packages/amd64/ pkg_add g++-4.6.3p6
(or just pkg_add http://www.mirrorservice.org/pub/OpenBSD/5.2/packages/amd64/g++-4.6.3p6.tgz)
rm /usr/bin/g++ ln -s /usr/local/bin/eg++ /usr/bin/g++
I believe I did not try 4.2.1 til now because ./configure warned me that that GCC version is broken or slow or something.
[..]
But if so, why is not an uncaught exception error printed at gsc
termination on every platform (which is g++'s default behavior)???
No, the runtime system should catch this exception in the ___BEGIN_TRY / ___END_TRY macros which are called in lib/setup.c (in only 2 places, so it should be easy to verify that the exception is actually caught by adding some printfs in the code).
Right, so that's really funny.
Quite soon I'll try compiling Gambit on the 5.2 and maybe snapshot with different versions of both GCC and G++ including 4.2.1, and report the results here.
Best regards, Mikael