[CoinBinary] Building JNI-based under MinGW

[Ted Ralphs]

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
https://projects.coin-or.org/BuildTools/wiki/current-issues#Compilation).
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.

Cheers,

Ted

On Thu, Jul 26, 2012 at 7:00 PM, <acw at ascent.com> wrote:

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




-- 
Dr. Ted Ralphs
Associate Professor, Lehigh University
(610) 628-1280
ted 'at' lehigh 'dot' edu
coral.ie.lehigh.edu/~ted <http://coral.ie.lehigh.edu/%7Eted>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/coinbinary/attachments/20120726/0f87ab48/attachment.html>