The reason for the use of the sjlj version of gcc was simply because it was the first version that I finally got the full CoinAll suite to build and pass unit tests with and it has continued to work year after year. Every other version of the MinGW compilers I've tried (and there have been many) has failed, usually in a strange way that's hard to interpret. Plainly, most versions of the MinGW compiler suite just seem buggy/flaky. Version 4.2.1 was the one version that seemed robust and just worked (though I did have to fix a buggy .la file, even in that version: see issue described at <a href="https://projects.coin-or.org/BuildTools/wiki/current-issues#Compilation">https://projects.coin-or.org/BuildTools/wiki/current-issues#Compilation</a>). Coincidentally (or perhaps not), this is the exact same version that still ships with XCode on the Mac. I will give another try to building with some later versions and see how it goes.<br>
<br>Cheers,<br><br>Ted<br><br><div class="gmail_quote">On Thu, Jul 26, 2012 at 7:00 PM, <span dir="ltr"><<a href="mailto:acw@ascent.com" target="_blank">acw@ascent.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font face="sans-serif">I appreciate the response, and figured
from the delay that it wasn't an easy task to port to Win64. For
the moment, at least, we are just going to run in 32-bit mode on 64-bit
platforms; eventually, the MinGW community's compiler technology will catch
up. I did, in fact, try to build from source using one 64-bit MinGW
GCC, but wasn't even able to diagnose the failures I was getting -- it
was way outside my area of expertise, whatever that is.</font>
<br>
<br><font face="sans-serif">Another thing we should be keeping our
eyes on is exception-handling architecture. At the moment, CoinBinary
is doing its building with the deprecated SjLj architecture, rather than
the modern Dwarf 2 architecture, which has two disadvantages: 1. it ties
you to a compiler branch which is not being actively maintained by the
MinGW developers; and 2. SjLj incurs a processing cost whenever you enter
the scope of an exception handler, regardless of whether the exception
occurs. (Dwarf 2 has no processing cost for merely entering the scope
of a handler; all costs are incurred when the exception is actually thrown.
I don't know how they managed that.) I didn't understand the
explanation of why CoinBinary projects can't be built with a Dwarf 2 compiler,
though I am certainly willing to believe there are difficulties. These
difficulties must be surmounted eventually, though, because it doesn't
look as if anyone wants to spend any energy maintaining the SjLj compiler.</font>
<br>
<br><font face="sans-serif">Anyway, we're certainly up and running
for the moment, so this is really only a theoretical issue. Thanks
for all the help you've given.</font></blockquote></div><br><br clear="all"><br>-- <br>Dr. Ted Ralphs<br>Associate Professor, Lehigh University<br>(610) 628-1280<br>ted 'at' lehigh 'dot' edu<br><a href="http://coral.ie.lehigh.edu/%7Eted" target="_blank">coral.ie.lehigh.edu/~ted</a><br>
<br>