<font size=2 face="sans-serif">Perhaps I spoke too soon; I've done a little
more research since I sent yesterday's message. If I have not misunderstood
the case, Microsoft is still clinging to SjLj; their compiler suite produces
binaries that use SjLj, and so their system libraries are all SjLj-based.
Furthermore, Dw2 code cannot inter-operate with SjLj, so for the
moment, anything that runs in a Windows environment must be SjLj from cover
to cover. (This isn't quite accurate: the restriction is that a Dw2-style
exception can't unwind through an SjLj stack frame, like a Windows callback.)
So, at least for the Windows target, it is probably premature to try compiling
to Dw2. In Unix and Linux, however, Dw2 is probably worth trying
for the potential performance gain.</font>
<br>
<br><font size=2 face="sans-serif">In other news, I found a compiler suite
called TDM-GCC, under active development at least as late as last September,
which claims to produce SjLj binaries for both the 32-bit and 64-bit Windows
environment. When things settle down here a bit I intend to try their
wares: see </font><a href="http://tdm-gcc.tdragon.net/"><font size=2 face="sans-serif">http://tdm-gcc.tdragon.net/</font></a><font size=2 face="sans-serif">
for more details.</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Ted Ralphs <ted@Lehigh.EDU></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">acw@ascent.com</font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">CoinBinary@list.coin-or.org</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">07/26/2012 08:25 PM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: Building JNI-based under MinGW</font></table>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>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 </font><a href="https://projects.coin-or.org/BuildTools/wiki/current-issues#Compilation"><font size=3 color=blue><u>https://projects.coin-or.org/BuildTools/wiki/current-issues#Compilation</u></font></a><font size=3>).
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>
</font>
<br><font size=3>On Thu, Jul 26, 2012 at 7:00 PM, <</font><a href=mailto:acw@ascent.com target=_blank><font size=3 color=blue><u>acw@ascent.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3 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><font size=3>
<br>
</font><font size=3 face="sans-serif"><br>
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><font size=3> <br>
</font><font size=3 face="sans-serif"><br>
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>
<br><font size=3><br>
<br>
<br>
-- <br>
Dr. Ted Ralphs<br>
Associate Professor, Lehigh University<br>
(610) 628-1280<br>
ted 'at' lehigh 'dot' edu</font><font size=3 color=blue><u><br>
</u></font><a href=http://coral.ie.lehigh.edu/%7Eted target=_blank><font size=3 color=blue><u>coral.ie.lehigh.edu/~ted</u></font></a><font size=3><br>
</font>
<br>