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.
On Wed, 19 Jul 2006, Lyle J. wrote:
Seeing as I’m still a few steps behind you, could you comment on what you
had to do to get Ruby 1.8.4 to compile with MinGW? I actually downloaded the
“Current” version and not the “Candidate”, but the compile of the very first
source file (array.c, I think) bombs complaining of duplicate definitions of
gettimeofday().I’m glad to switch to either MinGW or the latest Visual C++, whatever the
community at large decides to do. But I am little concerned to have hit this
snag right out of the gate with MinGW.
that’s odd - i installed and compiled straight away… i’m at an airport
now
but it actually wrote up what i did - i’ll dig it out when i get back.
in any
case i assure you it can be done… make sure you’ve got mingw installed
correctly and do someting like
./configure --prefix=/c/usr/local && make && make install
good luck.
-a
On 7/18/06, Simon Kröger [email protected] wrote:
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.
Seeing as I’m still a few steps behind you, could you comment on what
you had to do to get Ruby 1.8.4 to compile with MinGW? I actually
downloaded the “Current” version and not the “Candidate”, but the
compile of the very first source file (array.c, I think) bombs
complaining of duplicate definitions of gettimeofday().
I’m glad to switch to either MinGW or the latest Visual C++, whatever
the community at large decides to do. But I am little concerned to
have hit this snag right out of the gate with MinGW.
On 7/18/06, [email protected] [email protected] wrote:
definitions of
but it actually wrote up what i did - i’ll dig it out when i get back. in
any
case i assure you it can be done… make sure you’ve got mingw installed
correctly and do someting like./configure --prefix=/c/usr/local && make && make install
good luck.
Ara, could you please post a link to your MinGW writeup to this thread.
Thanks,
Curt
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.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.
Having used MS C since before it became Visual I can certainly attest
to it being a strong compiler. However, over the past few years it
seems as if MS has gone out of its way to alienate long term users of
their programming products. And it’s not just the incompatibilities
introduced in VS.NET - look at what’s happened to VB, OLE and MFC.
People spent 10 years becoming expert in these technologies just to
see them thrown away.
My experience is that you cannot write code using an MS platform and
expect it to be even compilable 5 years later. This is one of the main
reasons why I have switched to Open Source wherever possible - I have
code I wrote 20 years ago written in K&R C that still compiles and
works but anything I wrote in the 90s is a complete write-off.
As for the toolchain - while it may seem alien to people who have only
ever programmed with MS products, it really isn’t that hard to get
your head around. More and more people are developing in a mixed
environment - e.g. coding on Windows workstations and deploying on
Linux servers. To have one set of tools and commands to remember makes
a lot of sense.
As for MS products being more compatible with Windows - if you’ve ever
come across the problem of trying to compile across different versions
of MSCVRT*.DLL you’ll find that hard to swallow.
Personally I’m not interested in the slightest in making Ruby more
friendly to Windows but I am interested in making Windows more
friendly to Ruby.
Nearly all the good stuff we enjoy in Ruby on Windows comes from its
*nix background - using MinGW makes it a heck of a lot easier to
compile all those libs.
I say go for MinGW - it will still be here in 5 years time and it
narrows the gap between the Windows and *nix development environments.
My 2p
Regards,
Sean
From my experience using both tool chains on Windows (for the ruby-prof
extension and SWIG-based extensions for GEOS and GDAL).
-
You can build Ruby extensions using MingW that run against Ruby built
with VC++. I’ve done this with Ruby 1.8.2/1.8.4, various MingW releases
and VC++ 2003 and VC++ 2005. This used to require changing a small bug
in ruby.h for Ruby 1.8.2, but that bug has been fixed with 1.8.4. For
more info see
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=2206&group_id=426. -
However, you cannot do this with MingW using VC++ built Ruby.
ruby extconf.rb
make
make install
The problem is that extconf is quite limited - it will assume you are
building your extension with the same compiler that built Ruby (VC++).
Python avoids this issue because disutils will recognize the compiler
being used (MingW, VC++) for the extension and provide the correct
command line parameters.
-
If mkrf (http://glu.ttono.us/articles/2006/06/28/mkrf-0-1-0-released)
can work like Python distutils, then it will become simple to use MingW
to build extensions that work with VC++ -
When compiling with MingW do not link against the ruby *.lib files.
Instead, just link directly against the DLL (msvcrt-ruby18.dll). Its
faster (links much faster) and works better. -
So you need to manually compile your extension or create a makefile to
do it. This actually turns out be the way GEOS and GDAL work - they
have autoconf based build systems so extconf.rb wouldn’t fit in anyway. -
The advantage of MingW is that it avoids the unmanaged assemblies that
VC++8 uses, so its simpler to deal with (this is a good link about
manage assemblies -
http://www.grimes.demon.co.uk/workshops/fusWSThirteen.htm) -
VC++ has several large advantages on Windows.
First, it lets you debug your extensions while GDB does not support this
on Windows (or if it does, its never worked for me).
Second, it compiles much faster
Third, there is a lot more help available.
Forth, its quite easy to build Ruby extensions.
-
Using MingW on Windows is a huge barrier to entry. Gettting MingW
setup, along with msys, is a time consuming process that only
experienced *Nix developers will understand and be able to do. -
MingW on Windows is not very easy to use. Its nice to think that you
can download an open source project, type ./configure, make, make
install and it will work. Alas, it doesn’t really work that way. There
are myriad of issues you run into.
First you’ll need msys. Then many projects have prequisites that you’ll
have to download and compile. In addition, you often times have to
change the CFLAGS and LDFLAGS to get successful compiles. Linking is a
pain and requires hand-holding, and sometime just doesn’t work. Libtool
is really flakey on Windows. For some projects, you’ll have to need to
download/build/install the latest version of it. You also need to get
autoconf/automake installed. Many projects require bison - something
I’ve never been able to successfully compile on Windows. All in all - it
literally took me weeks to figure out how to get everything to work
together. The MingW/msys tool chain is quite complex on Windows, and
most people won’t have the time or desire to put forth the effort to get
it to work.
My recommendation:
-
Use VC++ 2005 and get Microsoft to tell us how to properly use
unmanaged assemblies so that we can avoid dll hell -
Make sure that mkrf supports building Ruby extensions
“out-of-the-box” on Windows using MingW if you have it installed.
I think this would be the best of both worlds - you support both tool
chains. VC++ is the default one, but MingW should work fine for
building extensions.
Hope this helps - I’d be glad to share more of my experiences if its
helpful.
Charlie
Forth, its quite easy to build Ruby extensions.
: Forth Ruby extensions BUILD> , DOES> quite-easy . ;
Sorry couldn’t resist,
Bill
Curt H. wrote:
be the
cons of choosing MinGW or VC2005. I need to fully understand the
implications before choosing a path.
Is cross-compiling/linking with GCC on a GNU platform a viable third
option? MinGW tends to lag “real” GCC. Given that you plan a Linux
release of the One-Click Ruby Installer, could you save yourself some
hassles with a cross-builder?
Bill K. wrote:
I recently compiled the RMagick extension on Windows,
and it was a complete hack job to get it to compile
with microsoft’s tools.
I’m sure Kaspar feels your pain
M. Edward (Ed) Borasky wrote:
Is cross-compiling/linking with GCC on a GNU platform a viable third
option? MinGW tends to lag “real” GCC. Given that you plan a Linux
release of the One-Click Ruby Installer, could you save yourself some
hassles with a cross-builder?
By the way, the people who build R for Windows have a very extensive
tool set. The build process, however, is complex, quite brittle and
changes often. I went through it once (on a laptop dual-booted with
Linux) and I must say if you’re good at following directions exactly
to the letter, you’ve got at least a 50% chance of a successful build.
Surely Microsoft makes something a little better than that.
Tim, I’m going to top reply since your post was so long. I’m interested
in
this, but I have some concerns.
This compiler problem started on the transition from VC++6 to VC++7
because
they used different runtime DLLs: msvcrt.dll and msvcrt71.dll (i think,
this
is from memory). All would be fine except that these dlls contain some
global variables.
The one that I know about is ERRNO. Some Windows api calls set ERRNO and
you
have to make a separate call to retrieve the error code. The problem
occurs
when the core Ruby is compiled with one version (VC++7 in the case of
the
1.8.2 one-click installer) and an extension that was built with the
other
version (VC++6). Subtle, hard-to-find bugs occurred when the api call
that
set ERRNO was made in one DLL while the call that checked ERRNO
happenned in
the other DLL.
This bug really occurred, and caused the Ruby core team to build the
compiler name into the external link symbols. This now prevents you from
mixing compilers between the Ruby core and any loaded extensions.
So, given this new fact of life, how is it that you were able to build
Ruby
with VC++2003 and VC++2005 and still load extensions built with MinGW?
And
if you did manage to work around the link errors that you get when you
try
to load an extension built with a different compiler, how did you manage
to
get them to use the same msvcrt*.dll runtime (or were you just unaware
of
this problem)?
Curt
Sean O’halpin wrote:
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.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.Having used MS C since before it became Visual I can certainly attest
to it being a strong compiler. However, over the past few years it
seems as if MS has gone out of its way to alienate long term users of
their programming products. And it’s not just the incompatibilities
introduced in VS.NET - look at what’s happened to VB, OLE and MFC.
MS needs to evolve also, do you expect MS to continue to enhance MS-DOS.
It can’t sit still while the competition passes it by and the fanatics
complain about security.
You can’t bitch about MS and then bitch because they try to make it
better.
People spent 10 years becoming expert in these technologies just to
see them thrown away.My experience is that you cannot write code using an MS platform and
expect it to be even compilable 5 years later. This is one of the main
reasons why I have switched to Open Source wherever possible - I have
code I wrote 20 years ago written in K&R C that still compiles and
works but anything I wrote in the 90s is a complete write-off.
You aren’t making any sense. MS is a very ANSI standard compiler, so if
you “truly” wrote it to be K&R it should work.
As for the toolchain - while it may seem alien to people who have only
ever programmed with MS products, it really isn’t that hard to get
your head around. More and more people are developing in a mixed
environment - e.g. coding on Windows workstations and deploying on
Linux servers. To have one set of tools and commands to remember makes
a lot of sense.
It make a lot of sense to those who have used it before.
It you are new to Ruby and need to compile it for the first and then
have to go thru the problem of setting up a toolchain, MinGW, etc…this
becomes a huge turnoff for using Ruby.
Windows products should use Windows compiler…VC++.
As for MS products being more compatible with Windows - if you’ve ever
come across the problem of trying to compile across different versions
of MSCVRT*.DLL you’ll find that hard to swallow.
I haven’t experienced, but I have heard of others who have.
Personally I’m not interested in the slightest in making Ruby more
friendly to Windows but I am interested in making Windows more
friendly to Ruby.
They you should leave this thread…we are trying to find a way to make
both sides happy and bring more users and developers to the Ruby
corner…Linux and Windows.
Nearly all the good stuff we enjoy in Ruby on Windows comes from its
*nix background - using MinGW makes it a heck of a lot easier to
compile all those libs.
This has NOTHING to do with which compiler to use for Windows.
Windows is Windows, not *nix!
You are just a Windows hater and your comments don’t hold any weight
here.
I say go for MinGW - it will still be here in 5 years time and it
narrows the gap between the Windows and *nix development environments.
But it widens the gap on Windows and the evolution of Windows.
On 7/19/06, Reggie Mr [email protected] wrote:
You aren’t making any sense. MS is a very ANSI standard compiler, so if
you “truly” wrote it to be K&R it should work.
Sean’s making plenty of sense. His K&R code does still work. It’s the
code he wrote since then using certain MS technologies that is a
complete write-off.
have to go thru the problem of setting up a toolchain, MinGW, etc…this
becomes a huge turnoff for using Ruby.
No one is suggesting that every windows user will have to compile
their own binaries. We are talking about which compiler extension
writers and the One-Click-Installer team should use. End users
shouldn’t know the difference.
Windows products should use Windows compiler…VC++.
And Ruby is a Windows product???
You are just a Windows hater and your comments don’t hold any weight
here.
Huh??? Perhaps you meant *nix instead of Windows in that first
sentence. In either case I find Sean’s comments very relevent. Most of
the great extensions in Ruby as well as Ruby itself were built
originally in *nix environments. I know for me personally, people are
constantly asking me to create some Windows binaries for Ferret and
it’d be a lot easier for me if MinGW was the default compiler for Ruby
on Windows. As it is, Windows users will have to stick with the (much
slower) pure Ruby version for a little longer yet.
I say go for MinGW - it will still be here in 5 years time and it
narrows the gap between the Windows and *nix development environments.But it widens the gap on Windows and the evolution of Windows.
How so? Can you be more specific.
My vote is for MinGW.
Cheers,
Dave
Tim, I’m going to top reply since your post was so long. I’m interested in
this, but I have some concerns.
Charlie actually 
The one that I know about is ERRNO. Some Windows api calls set ERRNO and
you
have to make a separate call to retrieve the error code. The problem occurs
when the core Ruby is compiled with one version (VC++7 in the case of the
1.8.2 one-click installer) and an extension that was built with the other
version (VC++6). Subtle, hard-to-find bugs occurred when the api call that
set ERRNO was made in one DLL while the call that checked ERRNO
happenned in
the other DLL.
Right - this should not work, as Microsoft’s documentation says, since
you’re setting two different ERRNO global variables, one per linked CRT
(Potential Errors Passing CRT Objects Across DLL Boundaries | Microsoft Learn).
And as I’m sure you know, Microsoft has decided to try and solve DLL
hell by tying the last three versions of VC++ to specific runtime
libraries. So VS.NET uses msvcr70.dll, VS 2003 uses msvcr71.dll and VS
2005 uses msvcr80.dll. They are not supposed to be mixed together.
For example, Python is built using msvcr71.dll (VS 2003). That means
you should build Python extensions with VS 2003 and not VC.NET or VS
2005.
So, given this new fact of life, how is it that you were able to build Ruby
with VC++2003 and VC++2005 and still load extensions built with MinGW?
I haven’t built Ruby itself, I’ve used the versions provided by the one
click installer (both 1.8.2 and 1.8.4).
And if you did manage to work around the link errors that you get when you try
to load an extension built with a different compiler, how did you manage to
get them to use the same msvcrt*.dll runtime (or were you just unaware of
this problem)?
MingW extensions link against msvcrt.dll. The version of the one click
installer that I have, a pre-release 1.8.4, appears to be built against
msvcrt.dll according to dependency walker
(http://www.dependencywalker.com/). So no issues there. And that would
have also been the case with Ruby 1.8.2.
When I build an extension with VC++ 2005, the extension links against
msvcr80.dll (never had compile/link issues with the Ruby headers and
libraries). Which means that two CRTs are now in play, msvcrt.dll and
msvcr80.dll (which is also dependent on msvcrt.dll). At this point you
have to be careful about passing CRT resources between the two CRTs or
else you’ll crash the program.
And I’d guess this is where my experience is different - for the
extensions I’ve built the communication between the extension and Ruby
has been done only via the Ruby C API. There haven’t been any examples,
like you mention above, where Ruby and the extension communicated via a
CRT function such as get_errno and set_errno.
What I don’t know the answer to is if you only use the Ruby api for
communication will it always be safe? Based on the extensions I’ve
built (ruby-prof, GDAL, GEOS, and the full SWIG ruby test suite) I
haven’t had problems. But that’s hardly conclusive proof. Would be a
good thing to follow up on with Microsoft.
Anyway, having pondered this a bit more…
-
Using VC 2005 really means that all extension writers should use VC
2005 also. If you use MingW, then you have to be careful. -
If you use MingW instead, then you’re saying all extension writers
should use MingW. If they use VC 2005, then you’re back in the same
boat. -
Worst of all is probably having different binary extensions compiled
with different versions of VC++.
If using just the Ruby API is safe, then in theory these combinations
could be made to work (unless there lots of examples like the one you
mention above). If its not, then the only solution is everyone uses the
same compiler always and forever for a given Ruby release. Which the
odds of that happening are probably somewhere around 0 
Charlie
P.S. - Great work on the one-click installer, you guys have done a
wonderful job.
And you have to count external DLLs - Iconv, SSLeay, PDcurses,
etc.
Yup. Are those all compiled together for the one click installer or
not? And are they compiled with the shared CRT or static CRTs?
Can you let other products use Ruby API?
Not sure what you mean?
The possible (and perhaps the only) way would be compiling all
sources by yourself.
Yes, I think that Ruby and its supporting DLLs need to be compiled with
the same compiler. Hopefully that is all done at once on a build
machine???
I’m wondering though if you can reliably use a different compiler for
building extensions (which seems ok in my experience).
Charlie
On 7/19/06, David B. [email protected] wrote:
My vote is for MinGW.
Mine too. MinGW + MSYS is great, just what I have been looking for,
and it seems much faster than Cygwin.
Sorry to pollute this thread but may I ask which MinGW/MSYS you use?
The download page is massive and the “current” and “candidate”
sections don’t even have a windows installer. I finally used
MinGW-3.1.0-1.exe and MSYS-1.0.9.exe from “previous”. I now see
there’s “proposed” right at the bottom with MinGW-5.0.2.exe but no
MSYS. What is best for building Ruby?
Les
Sean O’Halpin wrote:
People spent 10 years becoming expert in these technologies just to
see them thrown away.
in some cases, its called progress.
Nearly all the good stuff we enjoy in Ruby on Windows comes from its
*nix background - using MinGW makes it a heck of a lot easier to
compile all those libs.
it just proves ruby is full of unixism and is unixcentric as opposed to
being
windows centric. Thats its heratige, it was written on unix and uses
what it knows.
Now me, I feel left out in the cold since I use OpenWatcom…
the problem I think, ruby assumes too much about your system.
what needs to be done with the one click installer is not have it
assume its
on the system that built it. it would be nice, if there was a generic
config
that could be changed so MAKE=nmake.exe and CC=cl.exe that overrides
whatever ruby is assuming…
There is no real easy way out and I tink that mingw will/should get
ratified
as ‘TheOne™’. As long as people understand that MinGW is minimal and
some full blown ‘./configure && make’ its not designed to be cygwin,
that Min is for Minimal.
In the ruby extension case, ‘minimal’ should be enough to build any
required extensions.
Now packaging it with the one click installer would be nice, we could
assume then (ooh assumptions!) that a specific version of ruby on
windows will have a specific version of mingw + supporting cast
members…
-stu
Hi,
At Wed, 19 Jul 2006 14:49:28 +0900,
Charlie S. wrote in [ruby-core:08267]:
When I build an extension with VC++ 2005, the extension links against
msvcr80.dll (never had compile/link issues with the Ruby headers and
libraries). Which means that two CRTs are now in play, msvcrt.dll and
msvcr80.dll (which is also dependent on msvcrt.dll). At this point you
have to be careful about passing CRT resources between the two CRTs or
else you’ll crash the program.
And you have to count external DLLs - Iconv, SSLeay, PDcurses,
etc.
And I’d guess this is where my experience is different - for the
extensions I’ve built the communication between the extension and Ruby
has been done only via the Ruby C API. There haven’t been any examples,
like you mention above, where Ruby and the extension communicated via a
CRT function such as get_errno and set_errno.
Can you let other products use Ruby API?
The possible (and perhaps the only) way would be compiling all
sources by yourself.
Curt H. wrote:
succinctly as possible) is what the pros and cons are for each path.
Curt
Can you freely distribute VS2005 Express, or must a user who wants to
build extensions with it acquire it themselves?
Can you freely distribute MinGW, or must a user who wants to build
extensions with it acquire it themselves?
My point here is that a “one-click Ruby installer” should have the
option to install a toolset for building extensions if the user doesn’t
already have that toolset. When I built the LyX editor on Windows, it
pointed me to URLs for all of the things I needed (MikTeX, Python, etc.)
That makes a lot of sense for LyX; MiKTeX is huge. But I would have
preferred as much of the toolset bundled.
On 7/19/06, Charlie S. [email protected] wrote:
Tim, I’m going to top reply since your post was so long. I’m interested
in
this, but I have some concerns.Charlie actually
Oops… sorry!
set ERRNO was made in one DLL while the call that checked ERRNO
2005 uses msvcr80.dll. They are not supposed to be mixed together.msvcrt.dll according to dependency walker
(http://www.dependencywalker.com/). So no issues there. And that would
have also been the case with Ruby 1.8.2.
The 1.8.2 version of the one-click installer was built with VC++7.1
(aka
VS2003). This is where the ERRNO problem first surfaced because most of
the
third party extensions built by others used VC++6 or MinGW.
When I build an extension with VC++ 2005, the extension links against
msvcr80.dll (never had compile/link issues with the Ruby headers and
libraries). Which means that two CRTs are now in play, msvcrt.dll and
msvcr80.dll (which is also dependent on msvcrt.dll). At this point you
have to be careful about passing CRT resources between the two CRTs or
else you’ll crash the program.
This isn’t where you would see the errors. Its when you build Ruby using
VC++ 2005 and then try to load an extension that was built with any
other
compiler.
And I’d guess this is where my experience is different - for the
Anyway, having pondered this a bit more…
Using VC 2005 really means that all extension writers should use VC
2005 also. If you use MingW, then you have to be careful.If you use MingW instead, then you’re saying all extension writers
should use MingW. If they use VC 2005, then you’re back in the same boat.Worst of all is probably having different binary extensions compiled
with different versions of VC++.
This is the whole point of this thread. It appears that the only safe
thing
is that the Ruby runtime and all extensions that its uses (both those
included with the one-click installer and those provided by third
parties)
need to be using the same compiler and that compiler needs to be freely
available.
I have two choices VS2005 Express and MinGW. What I really want to know
(as
succinctly as possible) is what the pros and cons are for each path.
Curt
If using just the Ruby API is safe, then in theory these combinations
could be made to work (unless there lots of examples like the one you
mention above). If its not, then the only solution is everyone uses the
same compiler always and forever for a given Ruby release. Which the
odds of that happening are probably somewhere around 0
Charlie