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