<div><br></div>Looks like this was because of some weird version incompatibility issue between libc or libstdc++ versions.<div><br></div><div>I tried to track it down with ldd and didn't find it in a clear way, though, since with certain libc and libstdc++ choices this error goes away, it should plausibly have been in the first place because of version incompatibility.<div>

<br></div><div>Generally on OBSD only the default GCC version is used, and use of G++ is not so much discussed, in particular not non-bundled versions of it, so there seem to be no clarification to get on this topic out there also.</div>

<div><br></div><div>I read on a blog somewhere something like that if you have two two libstdc++ versions at the same time, it can be that the exception handling helper code gets loaded from another one than your application was compiled for and that you get undefined behavior and crashes that way. Don't remember right now if that was relevant to this though right now I'd think so.</div>

<div><br></div><div>For now I relate to it as solved anyhow as for the OBSD versions I saw there's at least one G++ + GCC package that works well for compiling and executing Gambit.</div><div><br></div><div>Thanks,</div>

<div>Mikael</div><div><br><div class="gmail_quote">2013/1/12 Mikael<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Marc,<div><br></div><div>Now had the occasion to go through if Gambit termination works on different GCC & G++ versions in OpenBSD 5.2 AMD64 default.</div>

<div><br></div><div>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.</div>




<div><br></div><div>This test make clear that there is a way to get Gambit going without issues on OBSD, so,</div><div><br></div><div>As far as I'm personally concerned this is a solved issue.</div><div><br></div><div>




<br></div><div><br></div><div>For completeness, here are the results:</div><div><br></div><div>Correct behavior of Gambit termination for different GCC & G++ versions on OBSD 5.2 AMD64 non-snapshot is as follows:</div>




<div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>gcc (GCC) 4.2.1 20070719 (this is the bundled version): Worked. (also ./configure --enable-single-host worked)</div><div>g++ (GCC) 4.2.1 20070719 (this is the bundled version): Worked.</div>




<div><br></div><div>egcc (GCC) 4.6.3: Worked.</div><div>eg++ (GCC) 4.6.3: Worked.</div><div><br></div><div>egcc (GCC) 4.7.1: Worked.</div><div>eg++ (GCC) 4.7.1: FAIL</div></div><div><br></div></blockquote></div><div><div>




For GCC compilation, ./configure --enable-single-host --enable-debug was used.</div><div>For G++ compilation, ./configure --enable-single-host --enable-debug --enable-cplusplus was used.</div><div><br></div><div>For invocation of the non-default version, CC=/usr/local/bin/egcc or CXX=/usr/local/bin/eg++ respectively was</div>




<div>added as prefix to the ./configure command line, in bash.</div><div><br></div><div>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.</div>




</div><div><br></div><div>Gambit compiled with eg++ (GCC) 4.7.1 produces the following in response to ,q :</div><div class="im"><div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>

<font face="courier new, monospace">Gambit v4.6.6</font></div>


<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">> ,q</font></div><div><font face="courier new, monospace">terminate called after throwing an instance of '___throw_struct'</font></div>




<div><font face="courier new, monospace">terminate called recursively</font></div><div><font face="courier new, monospace">Abort trap (core dumped)</font></div></div></blockquote></div><div><br></div><div><br></div></div>

<div>

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.</div>



<div><br></div><div><br></div><div><div>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.</div>


</div><div><br></div><div><br></div>
<div><br></div><div>If there would be any checks I could do for completeness at some point, feel free to mention them.</div><div><br></div><div>Thanks and with best regards,</div><div>Mikael</div><div class="HOEnZb"><div class="h5">

<div><br></div></div></div></blockquote><div> </div></div></div></div>