One-Click Installer: MinGW? or VC2005?

The O.-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of
subtle
incompatibilities and has, consequently, become a big headache for me
and
extension writers.

I need to decide whether future versions of the One-Click Installer are
built with MinGW or MS VC2005 Express (both compilers are free). My bias
has
been to go with VC2005 on the theory that the MS compiler will always be
the
most compatible with Windows, itself.

However, Ara Howard makes a case (see below) for MinGW, so I want to
have a
public discussion of the pros and cons of each path (please don’t
suggest
cygwin, it snot an option).

I’d like to ask that only those who have actual experience compiling
extensions for Ruby respond and that we keep the discussion to the pros
and
cons of choosing MinGW or VC2005. I need to fully understand the
implications before choosing a path.

Thanks,
Curt

PS
Below, Ara argues that a VC2005 version of Ruby would be unable
to compile/use extensions built with the command sequence:

ruby extconf.rb
make
make install

Isn’t this incorrect? Wouldn’t the sequence just become:

ruby extconf.rb
nmake
nmake install

If I’m wrong here, please let me know.

I just posted this to ruby-talk. But I would also like to discuss this
separately on ruby-core where this is a higher level of expertise, and a
lot
less noise.

Please read this and let me know what you think.

Thank you,
Curt

---------- Forwarded message ----------
From: Curt H. [email protected]
Date: Jul 18, 2006 10:22 AM
Subject: One-Click Installer: MinGW? or VC2005?
To: ruby-talk ML [email protected]

The O.-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of
subtle
incompatibilities and has, consequently, become a big headache for me
and
extension writers.

I need to decide whether future versions of the One-Click Installer are
built with MinGW or MS VC2005 Express (both compilers are free). My bias
has
been to go with VC2005 on the theory that the MS compiler will always be
the
most compatible with Windows, itself.

However, Ara Howard makes a case (see below) for MinGW, so I want to
have a
public discussion of the pros and cons of each path (please don’t
suggest
cygwin, it snot an option).

I’d like to ask that only those who have actual experience compiling
extensions for Ruby respond and that we keep the discussion to the pros
and
cons of choosing MinGW or VC2005. I need to fully understand the
implications before choosing a path.

Thanks,
Curt

PS
Below, Ara argues that a VC2005 version of Ruby would be unable
to compile/use extensions built with the command sequence:

ruby extconf.rb
make
make install

Isn’t this incorrect? Wouldn’t the sequence just become:

ruby extconf.rb
nmake
nmake install

If I’m wrong here, please let me know.

On 7/18/06, Curt H. [email protected] wrote:

I just posted this to ruby-talk. But I would also like to discuss this
separately on ruby-core where this is a higher level of expertise, and a
lot
less noise.

Please read this and let me know what you think.

Thank you,
Curt

How does Python handle this? I know they’re quite aggressive about
supplying
broadly-tested binary releases of the language itself, but how does that
affect extension writers? Do we have anything to learn (positive or
negative) from their experiences?

On 7/18/06, [email protected] [email protected] wrote:

windows.
web server) process using sqlite will have the entire library in
generate
be able hack things up - then again maybe not…
people who
impossible

create
MAKEDIRS: mkdir -p

it’s
‘compatible’ with microsoft as a microsoft produced compiler - common
cheers.
Thanks for taking the time to post such a detailed account. Now that you
mention it, I have encountered the very same problem myself with
OpenSSL. I
actually gave up trying to solve the compile problem when I found a
pre-built binary for OpenSSL.

Curt

On Wed, 19 Jul 2006, Curt H. wrote:

hi curt-

PS
Below, Ara argues that a VC2005 version of Ruby would be unable
to compile/use extensions built with the command sequence:

not unable - but with a significant amount of work.

If I’m wrong here, please let me know.

let’s take two common examples, sqlite and gsl. in both cases you are
going
to first need to compile the project itself, and then the ruby extension
written against it.

sqlite :

 - get on google and search for how to build sqlite from source on 

windows.
it doesn’t come setup to do this. here are some example
instructions

     http://initd.org/pub/software/pysqlite/doc/install-source-win32.html

   now, perhaps these are relevant and perhaps they're not.  in 

particular
note that the build is for a static library, meaning every ruby
(think
web server) process using sqlite will have the entire library in
memory.
note also that the build require gnu make (like everything else
on the
planet). most people will unlikely make it past this step.

 - get the ruby-sqlite bindings.  run ruby extconf.rb.  type make. 

oops,
you installed ruby into a slightly different place than the
person who
build the one-click, who also used nmake. see, extconf.rb will
generate
a makefile using all the environment settings used at the time
ruby was
built, which will be one of the one-click installer maintainers’
machines , not the end user. so, in order for extconf.rb to
generate a
workable makefile the entire environment used to build ruby
must
exist on the end users platform. this may or may not be a hard
thing to
get right. of course, for something simple like sqlite the end
user may
be able hack things up - then again maybe not…

 - alternatively we can require that windows users get pre-built 

binaries for
sqlite and ruby-sqlite. this places the burden of maintaintance
on the
very people who are already writing the free code! in addition,
it’s not
that easy to provide binaries that will be compatible for all
archs and
all versions of windows. also, we cut out tens of thousands of
people who
might contribute patches to these projects since they get nothing
but a
box of bits.

gsl :

 - get on google and learn how to compile gsl for windows.  note 

that the
first four google hits have titles like ‘ha ha ha’ and ‘nearly
impossible
to compile GSL for >> windows’. note that the fifth link is a
commercial
company selling a vc++ compiled gsl for $395.

     http://www.google.com/search?num=100&hl=en&lr=&q=how+to+compile+gsl+for+windows&btnG=Search

   dispair.

now, if one downloads mingw one gets a compile, make, and bunches of
other
good stuff all at once. both sqlite and gsl can be compiled in minutes
using

./configure --prefix=/c/usr/local && make && make install

same goes for ruby - compiles without a hitch. next we can download the
sqlite and gsl bindings and simply do

ruby extconf.rb && make && make install

done.

the crux of the issue isn’t that vc++ is a bad compiler - it’s obviously
not -
it’s that many, many good ruby extensions are actually just hooks into
3rd
parth software which, itself, requires a ‘minimal system’ to compile:
sh, ld,
ar, gcc, etc. and that it’s precisely this ‘minimal system’, not only
the
compiler, which is ‘remembered’ by ruby during compile time and used to
create
rbconfig.rb, which is the foundation of mkmf.rb and extconf.rb. it’s
interesting to run this command on a machine where ruby is installed:

ruby -r yaml -r rbconfig -e’ y Config::CONFIG ’

do so and you’ll see all sorts of stuff ruby considers important for
building
and installing things like


MAKEDIRS: mkdir -p

AR: ar

LN_S: ln -s

RANLIB: ranlib

LDSHARED: gcc -shared

YACC: bison -y

STRIP: strip -S -x

NROFF: /usr/bin/nroff

INSTALL_PROGRAM: /usr/bin/install -c

and this is only the tip of the iceberg - none of which include the
compiler
itself. ruby considers these programs essential for building itself and
it’s
totally legit for any extension to make use of these values during
configure/build time and, in fact, many do. these programs may or may
not
have to exist on end users machines in the same location (or at least in
PATH)
and the one-click builder’s machine for them to be used. so, this is an
example ‘minimal system’ ruby might use and, by coincidence, is very
similar
the the environment provided by mingw.

now, that’s the for. here’s the against: i can’t swear that mingw is as
‘compatible’ with microsoft as a microsoft produced compiler - common
sense
says it will not be. on the other hand, microsoft seems to have
compatibilty
issues even between it’s own compilers so maybe this gut feeling is
wrong. in
any case i’m not expert here and would defer to illumination from one.

one last thing - thanks so much for doing this work curt, community is
far
better for it.

cheers.

-a

On Wed, 19 Jul 2006, Curt H. wrote:

Thanks for taking the time to post such a detailed account. Now that you
mention it, I have encountered the very same problem myself with OpenSSL. I
actually gave up trying to solve the compile problem when I found a
pre-built binary for OpenSSL.

right. the question is whether it’s reasonable and/or healthly for the
ruby
community to require pre-built binaries for every peice of third party
software or not? my personal feeling is that be making that
requirement, no
matter which compiler you choose, you’ll see abi incompats because who
knows
what, for example, the openssl guy used. it just seems like the only
way out
is to at least provide an easy path for people who want to build stuff
because
otherwise it’s like you have to get everyone, including 3rd party people
and
extension writers, to agree on one compiler and that seems, frankly,
impossible.

the caveat, however, is whether mingw can cut the mustard. i’ve not
heard any
reason why it couldn’t - but i am simply not experience enough on
windoze to
know for sure.

kind regards.

-a

Hello,

In message “Re: One-Click Installer: MinGW? or VC2005?”
on Jul.19,2006 00:38:53, [email protected] wrote:
| How does Python handle this? I know they’re quite aggressive about supplying
| broadly-tested binary releases of the language itself, but how does that
| affect extension writers? Do we have anything to learn (positive or
| negative) from their experiences?

I’ve checked Python 2.4 Windows Installer.
It is compiled by VC7.1(VS.NET2003).

It bundles Tcl/Tk, and it’s compiled by VC7.1, too.

Another 3rd party libraries are static linked with python’s
extensions, but they are compiled by VC7.1, too.

The package includes libpython24.a.
I guess that it’s for MinGW support, but I doubt this is not
enough to support MinGW.

Regards,

Hello,

In message “One-Click Installer: MinGW? or VC2005?”
on Jul.19,2006 00:24:12, [email protected] wrote:
| I’d like to ask that only those who have actual experience compiling
| extensions for Ruby respond and that we keep the discussion to the pros and
| cons of choosing MinGW or VC2005. I need to fully understand the
| implications before choosing a path.

Even if you choose either, you will have to compile all sources
by the compiler as which you chose.
Therefore, I think you should choose easy one for you.
The person who complains anyway will show up even if you choose
either.

BTW, I like VC6 and MinGW.
Because they use MSVCRT.dll, not MSVCRxx.dll.

And, FYI:
After a while, a new port named x64-mswin64 is scheduled to be
supported on 1.9.
It’s able to compile only by VS2005, and at present there is
no plan to support x64 by MinGW.
This information is offered only to perplex you, Curt :slight_smile:

Regards,

On 7/18/06, Curt H. [email protected] wrote:

The O.-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of subtle
incompatibilities and has, consequently, become a big headache for me and
extension writers.

There’s one issue we may be finessing. What about installations (like
production servers) where it’s not acceptable to load a compiler at all?
My
gut says that this is an important issue going forward, especially as
Ruby
applications start getting used in enterprise environments. If you
accept
that, then the implication for this discussion is that extension writers
really do need to start compiling and testing for a variety of possible
Windows environments. Moreover, it means that binary-distro gems may
need to
be smart enough to carry more than one set of bits. We’ll have this
issue
regardless of the choice you make between VC and MinGW, Curt.

What does that mean for non-Ruby packages like sqllite and openssl? It
may
mean that we need to provide custom distros of these libraries wrapped
into
Ruby-gems that know how to interact with how we sense what’s in the
environment when we install. If this sounds like a total pain in the
tail:
it is, but my point is that we’re not doing our users any favors by
shifting
the pain onto them. My personal point of view (which many of you may
reasonably disagree with) is that Ruby applications should gain the
reputation of being braindead-easy to install on nearly any machine. For
better or worse, that means a lot more attention paid by developers
(that’s
us) to these issues.

Good points. I ran into similar things trying to build LDAP and Qt in
Ruby on my One-Click Installer enviornment. If I was savvy and diligent
enough I would have manually compiled Ruby in a separate directory and
then used that as my environment to build other additional libraries.
Perhaps one Ruby directory for a mingw build, another for a msvc build,
another for a bcc build, etc. That way I would have my bases covered.

But I took the lazy way out and coded my LDAP solution using Python’s
Win32 LDAP library that worked out of the box and found a prebuilt
binary for Qt that was released for Ruby 1.6.8 and reverted back to
that Ruby version to get Qt going on my Windows system while still
enjoying doing it using Ruby.

On 7/18/06, U.Nakamura [email protected] wrote:

Even if you choose either, you will have to compile all sources
by the compiler as which you chose.
Therefore, I think you should choose easy one for you.
The person who complains anyway will show up even if you choose
either.

BTW, I like VC6 and MinGW.
Because they use MSVCRT.dll, not MSVCRxx.dll.

I also prefer VC6, and I would stick with it except that it is no longer
available.

Are MinGW binaries compatible with VC6 binaries?

And, FYI:

After a while, a new port named x64-mswin64 is scheduled to be
supported on 1.9.
It’s able to compile only by VS2005, and at present there is
no plan to support x64 by MinGW.
This information is offered only to perplex you, Curt :slight_smile:

Well, that is another complication. But I also think it is something
that
needs to be considered.

Curt

unknown wrote:

regarding ruby stuff being ‘easy’ to install i’d say that opening up the
world
of editing source and compiling it will certainly bring in patches and
contributions - and those may be steps towards making ruby extensions
easier
to install be they binary or not.
<<<

This point was made upthread and is entirely valid. I’m not proposing
that people stop working with extensions in source code. But as Ruby
applications become more successful and acquire credibility for
production use, the lack of really seamless binary support in a range of
environments (including Windows flavors) becomes a barrier to adoption.
In a sense, I’m talking about enabling a community of users that today
have some good reasons to avoid Ruby.

You are right, though, this is orthogonal to the VC-MinGW choice and
belongs on its own thread.

On Wed, 19 Jul 2006, Francis C. wrote:

There’s one issue we may be finessing. What about installations (like
production servers) where it’s not acceptable to load a compiler at all? My
gut says that this is an important issue going forward, especially as Ruby
applications start getting used in enterprise environments. If you accept
that, then the implication for this discussion is that extension writers
really do need to start compiling and testing for a variety of possible
Windows environments. Moreover, it means that binary-distro gems may need to
be smart enough to carry more than one set of bits. We’ll have this issue
regardless of the choice you make between VC and MinGW, Curt.

exactly - this issue is orthogonal.

however, it would cetrainly simply things if the environment used to
build
ruby could also be used to compile third party extensions. take gsl for
example, i managed to compile it and the ruby extension via mingw - but
i
know the output from the compilers is subtly incompatible: for
instance
isascii is a macro on one and an function in the other (forget which).
i
worked around this by hacking the source - and neither compiler is to
blame
since ansi doesn’t specify behaviour here - but it makes me queasy
knowing
there are tiny differences between compiler abis. my personal feeling
is that
it’s the plethora of binary installs available to windows that makes it
so
dang unstable… but that’s another issue.

in any case a mingw based ruby certainly doesn’t preclude binary only
installs

  • indeed, rpms are binary and based on gnu tools.

regarding ruby stuff being ‘easy’ to install i’d say that opening up the
world
of editing source and compiling it will certainly bring in patches and
contributions - and those may be steps towards making ruby extensions
easier
to install be they binary or not.

cheers.

-a

On 7/18/06, Francis C. [email protected] wrote:

<<<
belongs on its own thread.
I think this is a fairly valid point though, and plays a point in this
discussion. Which of the two compiler tool chains, (as that is as much
what
we’re talking about as compilers themselves) will make it easiest for
extension and library providers to get binary installs on windows? My
feeling is that MinGW will make it easier for people that already
provide
extensions/libs on *nix to provide the same in Windows. The tool chain
is
the same or at least close enough to keep people sane.

Any compiler is an inconvenience to Windows users, so I think the real
decision lies with those that are providing extensions.

From: “Curt H.” [email protected]

ruby extconf.rb
nmake
nmake install

If I’m wrong here, please let me know.

Ara has already covered this in detail, but to clarify:

ruby extconf.rb
nmake
nmake install

can indeed work on Windows, for simple extensions.

It’s not uncommon, at a minimum, to have to tweak the
extconf.rb, though. Often an extconf.rb specifies
gcc-specific compiler flags, or looks for the presence
of libraries that are named differently, etc.

Sometimes it’s a simple fix, such as modifying the
extconf.rb to eliminate lines like:

CFLAGS << " -Wall -Wno-comment"
CFLAGS << " -Wno-unused"

…on the Windows build.

But for more complex extensions, building on windows
(with nmake and cl.exe) can be far less trivial.

I recently compiled the RMagick extension on Windows,
and it was a complete hack job to get it to compile
with microsoft’s tools.

First of all, RMagick uses ./configure to actually
build the extconf.rb from extconf.rb.in.
So there’s no extconf.rb to even work with initially.

It also uses ./configure to build a lengthy header
file, rmagick_config.h.

Ultimately, I ended up building RMagick on linux,
and bringing extconf.rb and rmagick_config.h back
to Windows, and tweaking them enough to compile with
nmake + cl.exe.

Here’s an example of the tweaks to extconf.rb:

Replace:

$CFLAGS = "-Wall -g "
$CPPFLAGS = “-DRUBY_VERSION=#{VERSION_NUMBER}
-I/opt/include/ImageMagick-6.2.8”

with:

$CFLAGS = “-DWIN32 -DRUBY_VERSION=#{VERSION_NUMBER}
-I…/…/…/ImageMagick-6.2.8”
$LIBPATH << “…/…/…/ImageMagick-6.2.8/VisualMagick/lib”

etc.

And I was lucky ImageMagick itself came with the
ability to build with Visual Studio. There are other
projects, such as the ones Ara mentioned, and puredata,
and (I think) ruby-gnome2 and ruby-gstreamer that don’t
build under visual studio at all.

So, yeah… If we could build ruby extensions AND the
libraries they rely on with ./configure && make, on
Windows… That sounds far nicer than the current hassles
I’ve had trying to build complex extensions and their
associated libraries with microsoft’s tools.

That said, I must admit… I tried to get mingw/msys to
work for me, and I had weird problems with it. I asked
for help in #mingw on irc.freenode.net on a couple
occasions, but never got a response. But clearly, Ara
has gotten it to work, so there’s hope.

Regards,

Bill

On 7/18/06, Tanner B. [email protected] wrote:

Any compiler is an inconvenience to Windows users, so I think the real
decision lies with those that are providing extensions.

You’ve nailed it here. The end users (Windows developers) want binaries
and
don’t want to fool with source. The real issue is making things easy for
those of us that provide the binaries.

Curt

On Wed, Jul 19, 2006 at 03:06:10AM +0900, Francis C. wrote:

In a sense, I’m talking about enabling a community of users that today
have some good reasons to avoid Ruby.

You are right, though, this is orthogonal to the VC-MinGW choice and
belongs on its own thread.

I believe that it is not entirely orthogonal. My gut feeling is that
MinGW
would make it easier to provide binaries, thanks to:

  • the toolchain being closer to that you have on un*x: this means that
    third party libs are often easier to compile than with VC 2005. Ara
    cited
    gsl. As you said, in the long term not only the extensions, but also
    the
    libs themselves would have to be provided in binary form.
  • the possibility to cross-compile (this is something I’ve repeatedly
    used myself)
  • its availability in time (is VC 2005 to end like VC6?)

On Wed, Jul 19, 2006 at 12:22:16AM +0900, Curt H. wrote:

The O.-Click Ruby Installer for Windows is at a cross-roads. The C++
compiler situation on Windows has become a complete mess because of subtle
incompatibilities and has, consequently, become a big headache for me and
extension writers.

I need to decide whether future versions of the One-Click Installer are
built with MinGW or MS VC2005 Express (both compilers are free). My bias has
been to go with VC2005 on the theory that the MS compiler will always be the
most compatible with Windows, itself.

Given that the current situation can be to a large extent attributed to
the
perverted mind of somebody at Microsoft who has consistently decided to
break
binary compatibility in (nearly all?) new releases of their compilers,
doesn’t
the burden of proof fall on VC2005? It seems to me that very heavy
evidence
would be needed to justify that choice, since it appears very likely to
lead to
problems like those we’re experiencing now, if any conclusion is to be
drawn
from recent history.

So far, we’ve seen the following arguments for MS VC2005 and MinGW,
respectively:
(1) VC 2005 should be more compatible with Windows
(2) MinGW (plus MSYS) provides an adequate environment to compile the
third-party libraries against which you want to link your Ruby
extension.

While (1) is likely, we can’t know the extent of any future
incompatibilities,
and it is indeed possible that the people behind MinGW keep them under
control. To my eyes, (1) is easily counter-balanced by the almost
certain
incompatibilities “with themselves” MS’ compilers seem bound to suffer
from,
given their track record. How long will VC 2005 live before it’s removed
from
MS’ sites?

However, the argument deserves careful consideration, so I’d ask for
reports
of current problems caused by MinGW. In other words, I’d like to see
actual
reasons why MinGW would not be a good choice right now: specific
problems
that can only be solved by switching to MS’ compiler of the day.

Here are a few other minor arguments for MinGW:

  • availability: MinGW will not disappear the way VC6 did
  • redistribution: is it allowed to redistribute VC 2005 at all? And to
    bundle
    it with other software? A “Ruby devel. kit” (in a similar spirit as
    Instant
    Rails) including MSYS+MinGW is at least conceivable – would it be
    legally
    possible with VC?
  • cross-compilation: one thing I like about MinGW is that it can be used
    to
    cross-compile extensions under non-win32 platforms. It allows me to
    provide
    win32 binaries for my extensions without having to use win32 myself. A
    few
    other people might also appreciate that. It could also simplify the
    creation
    of a build farm as proposed by Francis C…

There’s another probably more important reason to go MinGW: it offers an
easier migration path, as existing extensions compiled with VC6/MinGW
(which
might well be the majority, since recent OCI distros used the mswin32
build,
and the installer was built with VC6 historically, IIRC) would probably
still
work. However, I must admit I’m speculating since some people have
claimed
that MinGW-compiled extensions were not always compatible with VC6 Ruby
builds, although the reports were often vague. And I certainly don’t
remember
nobu saying that MinGW is incompatible, but rather the opposite.
Now, I don’t know if that “99% compatibility” is commutative or not,
either,
but I’d like to believe it is.

Again, I feel we’d have to be shown specific cases where MinGW was not
good
enough – there’s already ample evidence showing that it does, more
often than
not, work just fine. And at any rate, it’s still most probably better,
as far
as backwards compatibility goes, than VC 2005, which uses a different
runtime.

Mauricio F. wrote:

In a sense, I’m talking about enabling a community of users that today
libs themselves would have to be provided in binary form.

  • the possibility to cross-compile (this is something I’ve repeatedly used myself)
  • its availability in time (is VC 2005 to end like VC6?)

Actually i was about to say something like mingw is only easier if you
already
know linux tools, dll file format isn’t compiler dependent, windows
users don’t
want to fiddle with make and so on.

While i think this is all true i have to admit that it isn’t really
ruling out
mingw, so i downloaded and installed it (not for the first time).

I had a tough time figuring out that ruby 1.8.4 isn’t compiling
unmodified with
the ‘Candidate’ version and how to fix that. (and you do have to install
a lot
of third party libs if you want all the goodness of the one-click, or be
able
to use gems e.g.)

To be honest, i thought mingw would have performance problems on
windows, but
everything i tried so far is comparable, e.g.:

C:\development>ruby -v sodoku.rb sodoku.txt
ruby 1.8.4 (2005-12-24) [i386-mswin32]
user system total real
solving nr 1

solving nr 29 0.922000 0.000000 0.922000 ( 0.922000)
±------±------±------+
| 1 2 6 | 4 3 7 | 9 5 8 |
| 8 9 5 | 6 2 1 | 4 7 3 |
| 3 7 4 | 9 8 5 | 1 2 6 |
±------±------±------+
| 4 5 7 | 1 9 3 | 8 6 2 |
| 9 8 3 | 2 4 6 | 5 1 7 |
| 6 1 2 | 5 7 8 | 3 9 4 |
±------±------±------+
| 2 6 9 | 3 1 4 | 7 8 5 |
| 5 4 8 | 7 6 9 | 2 3 1 |
| 7 3 1 | 8 5 2 | 6 4 9 |
±------±------±------+
total 13.750000 0.047000 13.797000 ( 13.827000)
average 0.474138 0.001621 0.475759 ( 0.476793)

and mingw:

$ ruby -v sodoku.rb sodoku.txt
ruby 1.8.4 (2005-12-24) [i386-mingw32]
user system total real
solving nr 1

solving nr 29 0.640000 0.000000 0.640000 ( 0.640551)
±------±------±------+
| 1 2 6 | 4 3 7 | 9 5 8 |
| 8 9 5 | 6 2 1 | 4 7 3 |
| 3 7 4 | 9 8 5 | 1 2 6 |
±------±------±------+
| 4 5 7 | 1 9 3 | 8 6 2 |
| 9 8 3 | 2 4 6 | 5 1 7 |
| 6 1 2 | 5 7 8 | 3 9 4 |
±------±------±------+
| 2 6 9 | 3 1 4 | 7 8 5 |
| 5 4 8 | 7 6 9 | 2 3 1 |
| 7 3 1 | 8 5 2 | 6 4 9 |
±------±------±------+
total 10.031000 0.109000 10.140000 ( 10.139457)
average 0.345897 0.003759 0.349655 ( 0.349636)

It’s 25% faster. 8)

(gcc version 3.4.5 (mingw special))

Ok, go on Curt, i would like to see how a vc2005 build would compare to
this
but MinGW seems at least on par with vc6.

If on the long run we can have binaries for windows easier this way I’m
all for it.

cheers

Simon

On Wed, 19 Jul 2006, Francis C. wrote:

Seems to me the only benefit to VC is that it might somehow produce better
code, for some vague interpretation of “better.” At least until it gets
replaced by the next version and we all have to recompile.

and they have a stellar record at doing that… :wink:

-a