Thin on Windows reprise

[Chirag]

Could someone send me tell me how to run Thin on Windows? I tried gem
install thin, but get the below error. I also did gem install
eventmachine (0.8.1), but still no dice. Will I need to run Thin as a
Windows service?

Thanks, Chirag

C:\chirag\mindmap\HaloTrac>gem install thin
Building native extensions. This could take a while...
ERROR: Error installing thin:
ERROR: Failed to build gem native extension.

C:/ruby/bin/ruby.exe extconf.rb install thin
checking for windows.h... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details. You may need configuration options.

Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--srcdir=.
--curdir
--ruby=C:/ruby/bin/ruby


Gem files will remain installed in C:/ruby/lib/ruby/gems/1.8/gems/
eventmachine-0
.10.0 for inspection.
Results logged to C:/ruby/lib/ruby/gems/1.8/gems/eventmachine-0.10.0/
ext/gem_mak
e.out

[macournoyer]

Hey Chirag,

try:

gem install eventmachine -v0.8.1
gem install thin

I just committed a fix to install 0.8.1 only on windows, that should
allow to skip first step. Thx for reporting!

[winston]

Hi,

Thin requires the following dependencies:
1. Rack
2. EventMachine

Unfortunately, eventmachine 0.10.0 is not a win32 release, so it's
difficult to install it on windows. Instead, download a win32
eventmachine from http://rubyforge.org/frs/download.php/23665/eventmachine-win32-0.8.1.gem
. Even though the version is 0.8.1, however, I have not encountered
any problems so far with this version. Of course, I am only using
windows for development, and not for production.

I would say most would recommend you to go with eventmachine 0.10.0
(which would only work with *nix systems), for production env, as it's
more stable.

Anyway, follow these steps to install thin on windows:
1. install rack:
>> gem install rack

2. download eventmachine from http://rubyforge.org/frs/download.php/23665/eventmachine-win32-0.8.1.gem
>> gem install eventmachine -l

3. install thin, but ignore dependencies
>> gem install thin --ignore-dependencies

This should install thin successfully on windows.

cheers,
Winston

[Chirag]

winston, worked perfectly. thanks!

also thanks to macournoyer for making the fix in the code

[Josh Atkins]

Thank you so, so, much winston and macournoyer - Thin's now installed
perfectly on my Windows XP computer.

On Mar 15, 3:32 pm, winston <winston.yong...@gmail.com> wrote:
> Hi,
>
> Thin requires the following dependencies:
> 1. Rack
> 2. EventMachine
>
> Unfortunately, eventmachine 0.10.0 is not a win32 release, so it's
> difficult to install it on windows. Instead, download a win32

> eventmachine fromhttp://rubyforge.org/frs/download.php/23665/eventmachine-win32-0.8.1.gem

> . Even though the version is 0.8.1, however, I have not encountered
> any problems so far with this version. Of course, I am only using
> windows for development, and not for production.
>
> I would say most would recommend you to go with eventmachine 0.10.0
> (which would only work with *nix systems), for production env, as it's
> more stable.
>
> Anyway, follow these steps to install thin on windows:
> 1. install rack:
>
> >> gem install rack
>

> 2. download eventmachine fromhttp://rubyforge.org/frs/download.php/23665/eventmachine-win32-0.8.1.gem

[will]

Hi folks.

I was attempting to run the Ruby Thin demo application on Windows/XP
when I got an error that Windows couldn't find "msvcr90.dll" for Ruby
1.8.7 -- I found a redistributable and put that in my path to be
confronted with the information that:

"R6034 ... application has made an attempt to lead the C runtime
incorrectly"

Earlier today I ran a few eventmachine demos oK, so I am thinking that
the problem is with Thin.

The Ruby stack dump isn't that helpful ... (included below). Is there
a cure?

* Thin (1.2.2)
* Rack (1.0.0, 0.9.1, 0.4.0, 0.3.0) ......
* EventMachine (0.12.8) .................. eventmachine-0.12.8-x86-
mswin32-60

I've looked over the other MSVCR90.DLL posts here and on
stackoverflow, none of those cures work. The MSVCR90.DLL is now in
system32 -- I still get the "incorrectly linked" error with the: "ruby
adapter.rb" example.

Thanks in advance.

... Will

------
W:\> ruby adapter.rb
>> Thin web server (v1.2.2 codename I Find Your Lack of Sauce
Disturbing)
>> Maximum connections set to 1024
>> Listening on 127.0.0.1:3000, CTRL+C to stop
c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/thin-1.2.2/lib/
thin_parser.so: 1114: A dynamic link library (DLL) initialization
routine failed.
- c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/thin-1.2.2/lib/
thin_parser.so (LoadError)
from c:/bin/ruby/v1.8/lib/ruby/site_ruby/1.8/rubygems/
custom_require.rb:31:in `require'
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/thin-1.2.2/lib/
thin/request.rb:1
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/thin-1.2.2/lib/
thin/connection.rb:35:in `post_init'
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/
eventmachine-0.12.8-x86-mswin32-60/lib/em/connection.rb:43:in `new'
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/
eventmachine-0.12.8-x86-mswin32-60/lib/em/connection.rb:36:in
`instance_eval'
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/
eventmachine-0.12.8-x86-mswin32-60/lib/em/connection.rb:36:in `new'
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/
eventmachine-0.12.8-x86-mswin32-60/lib/eventmachine.rb:1490:in
`event_callback'
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/
eventmachine-0.12.8-x86-mswin32-60/lib/eventmachine.rb:242:in
`run_machine'
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/
eventmachine-0.12.8-x86-mswin32-60/lib/eventmachine.rb:242:in `run'
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/thin-1.2.2/lib/
thin/backends/base.rb:57:in `start'
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/thin-1.2.2/lib/
thin/server.rb:156:in `start!'
from c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/thin-1.2.2/lib/
thin/server.rb:142:in `start'
from adapter.rb:21

---------- Forwarded message ----------
From: winston <winston.yong...@gmail.com>
Date: Mar 16 2008, 1:32 am
Subject: Thin on Windows reprise
To: thin-ruby

Thin requires the following dependencies:
1. Rack
2. EventMachine

Unfortunately, eventmachine 0.10.0 is not a win32 release, so it's

difficult to install it onwindows. Instead, download a win32
eventmachine fromhttp://rubyforge.org/frs/download.php/23665/eventmachine-win32-0.8.1.gem

. Even though the version is 0.8.1, however, I have not encountered
any problems so far with this version. Of course, I am only

usingwindowsfor development, and not for production.

I would say most would recommend you to go with eventmachine 0.10.0
(which would only work with *nix systems), for production env, as it's
more stable.

Anyway, follow these steps to installthinonwindows:
1. install rack:

>> gem install rack

2. download eventmachine fromhttp://rubyforge.org/frs/download.php/23665/eventmachine-win32-0.8.1.gem

>> gem install eventmachine -l

3. installthin, but ignore dependencies

>> gem installthin--ignore-dependencies

This should installthinsuccessfully onwindows.

cheers,
Winston

On Mar 15, 11:57 am, Chirag <patel...@gmail.com> wrote:

> Could someone send me tell me how to runThinonWindows? I tried  gem

> installthin, but get the below error. I also did gem install

> eventmachine (0.8.1), but still no dice. Will I need to runThinas a
>Windowsservice?

> Thanks, Chirag

> C:\chirag\mindmap\HaloTrac>gem installthin
> Building native extensions.  This could take a while...
> ERROR:  Error installingthin:
>         ERROR: Failed to build gem native extension.

> C:/ruby/bin/ruby.exe extconf.rb installthin
> checking forwindows.h... no

[James Tucker]

On 17 Jul 2009, at 11:26, will wrote:

>
>
> Hi folks.
>
> I was attempting to run the Ruby Thin demo application on Windows/XP
> when I got an error that Windows couldn't find "msvcr90.dll" for Ruby
> 1.8.7 -- I found a redistributable and put that in my path to be
> confronted with the information that:
>
> "R6034 ... application has made an attempt to lead the C runtime
> incorrectly"
>
> Earlier today I ran a few eventmachine demos oK, so I am thinking that
> the problem is with Thin.
>
> The Ruby stack dump isn't that helpful ... (included below). Is there
> a cure?
>
> * Thin (1.2.2)
> * Rack (1.0.0, 0.9.1, 0.4.0, 0.3.0) ......
> * EventMachine (0.12.8) .................. eventmachine-0.12.8-x86-
> mswin32-60
>
> I've looked over the other MSVCR90.DLL posts here and on
> stackoverflow, none of those cures work. The MSVCR90.DLL is now in
> system32 -- I still get the "incorrectly linked" error with the: "ruby
> adapter.rb" example.

EventMachine x86-mswin32-60 is likely not entirely binary compatible
with libraries linked against msvcr9.

I would recommend you lookup some information on the potential impacts
of loading multiple msvc runtimes in the same process.

You should ensure that your interpreter and gems are all linked
against the same runtime. It is also worth noting that mingw/gcc
builds are compatible with x86-mswin32-60, or "msvcrt".

HTH

[will]

Thanks James

I'd definitely prefer to link with the same runtime as Ruby and the
EvnetMachine binaries. That would fall in my definition for a 'cure',
running one run-times is definitely more of "a cool day in the
woods". Which is what we did this afternoon, actually.


EvenMachine and Thin gems are BOTH incompatible with the Ruby 1.8 and
1.9 run-times, as I see it. This seems to be a victim of "compiler
default behaviour". Binaries compiled with the /MT flag shouldn't
need either of: MSVCR60.dll and MSVCR90.dll.


I've displayed some investigation steps (below) for people who need to
do some similar tracking. The Thin gem binary was linked to the
MSVC90 C++ and not to the same linkage as Ruby 1.8 and
rubyeventmachine.so and fastfilereaderext.so from eventmachine (see
the bin dump below).

I have been forced to give this whole RubyInline framework a good look-
see in recent weeks. The thing seems to be out of step with the
contemporary Windows build parameters. Anyway there are tools that
will help people.

The first one is dumpbin, where ever your visual studio (express)
edition is in the bin folder.

"C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\ ...

dumpbin.exe" /dependents rubyeventmachine.so

So I looked at Ruby, EventMachine and Thin

dumpbin.exe" /dependents ruby.exe [1.87p0]
dumpbin.exe" /dependents rubyeventmachine.so [x86-mswin32-60]
dumpbin.exe" /dependents fastfilereaderext.so [x86-mswin32-60]
dumpbin.exe" /dependents thin_parser.so [1.2.2]

Ruby itself only depends on MSVCRT.dll, the (generic) threaded C
runtime. The other dependency conflicts are apparently a side-effect
of something the gem brings with it, or the cpp build environment.
(The dumpbin outputs are below for the perverse among us.) For fun, I
also looked at Ruby 1.9; Ruby 1.9 ALSO does the right thing and only
depends on the generic threaded xxxRT.DLL.

My plea to gem builders, for "my version of a cure" -- Please creating
independent DLL-s for all the operating system (not depending of
specific compiler versions). No pun intended.

* Use the Multi-threaded (/MT)

Option for code generation when you build with a MS compiler, and this
need never happen again. Unless you WANT it to? Also you can use
dumpbin to verify everything is Ruby friendly.

One small rant; so turn-off now. When I started building C and C++
programs we had to set-up the libraries (.a or .lib) files so that we
were responsible for the bloat or speed of the final application along
with the correct function. No one wanted their product to suddenly
ship with an unplanned dependency; extra-added-slowness or added-
memory-hog with vitamins! *lol*

Ruby makes life easy; nevertheless if you delve into the C-code (or
Java-code) layers ... Be aware there be beasties out there. Above all
"do no harm". As would the /MT flag for rubyinline code and gem
builds.

My observation (rant is over now) is that there can be an over
enthusiasm to distrust the microsoft compilers and tools. That is
silly imho. I've been using MS compilers since 8-bit CP/M and DOS
they have always been high quality -- They are like all the top-line
tools, take RogueWave or Borland :: you need to be specific with your
options and build parameters. The defaults are naturally set-up to
make building MFC programs as nice as possible.

Best wishes,

Will

=======================================

Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.

Dump of file ... ruby.exe

File Type: EXECUTABLE IMAGE

Image has the following dependencies:

msvcrt-ruby18.dll
MSVCRT.dll

Summary

1000 .data
1000 .rdata
1000 .rsrc
1000 .text

Dump of file C:\bin\ruby\v1.8\lib\ruby\gems\1.8\gems\thin-1.2.2\lib
\thin_parser.so

File Type: DLL

Image has the following dependencies:

msvcrt-ruby18.dll
MSVCR90.dll
KERNEL32.dll

Summary

1000 .data
2000 .rdata
1000 .reloc
2000 .text


Dump of file ... rubyeventmachine.so

File Type: DLL

Image has the following dependencies:

msvcrt-ruby18.dll
RPCRT4.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
WS2_32.dll
MSVCP60.dll
MSVCRT.dll

Summary

15000 .data
2A000 .rdata
C000 .reloc
91000 .text

Dump of file ... fastfilereaderext.so

File Type: DLL

Image has the following dependencies:

msvcrt-ruby18.dll
KERNEL32.dll
MSVCP60.dll
MSVCRT.dll

On Jul 17, 10:54 pm, James Tucker <jftuc...@gmail.com> wrote:
> On 17 Jul 2009, at 11:26, will wrote:
>
> > I was attempting to run the Ruby Thin demo application on Windows/XP
> > when I got an error that Windows couldn't find "msvcr90.dll" for Ruby
> > 1.8.7 -- I found a redistributable and put that in my path to be
> > confronted with the information that:
>
> > "R6034 ... application has made an attempt to lead the C runtime
> > incorrectly"
>
> > Earlier today I ran a few eventmachine demos oK, so I am thinking that
> > the problem is with Thin.
>
> > The Ruby stack dump isn't that helpful ... (included below). Is there
> > a cure?
>
> > * Thin (1.2.2)
> > * Rack (1.0.0, 0.9.1, 0.4.0, 0.3.0) ......
> > * EventMachine (0.12.8) .................. eventmachine-0.12.8-x86-
> > mswin32-60
>

[rogerdpack]

> EvenMachine and Thin gems are BOTH incompatible with the Ruby 1.8 and
> 1.9 run-times, as I see it.  This seems to be a victim of "compiler
> default behaviour".  Binaries compiled with the /MT flag shouldn't
> need either of: MSVCR60.dll and MSVCR90.dll.

So is this just a question of compiling the libs with different
command line parameters?

> c:/bin/ruby/v1.8/lib/ruby/gems/1.8/gems/thin-1.2.2/lib/
thin_parser.so: 1114: A dynamic link library (DLL) initialization
routine failed.

Was thin compiled with a different compiler than eventmachine in this
instance, then?
Just wondering.
=r

[Alexey Borzenkov]

On Fri, Jul 17, 2009 at 2:26 PM, will<william....@gmail.com> wrote:
> I was attempting to run the Ruby Thin demo application on Windows/XP
> when I got an error that Windows couldn't find "msvcr90.dll" for Ruby
> 1.8.7 -- I found a redistributable and put that in my path to be
> confronted with the information that:

You cannot do that with recent Microsoft runtimes, because they should
not be loaded directly. You should copy a complete package (the
directory containing dlls and manifest) next to your .dll/.exe for
them to load correctly.

> I've looked over the other MSVCR90.DLL posts here and on
> stackoverflow, none of those cures work.  The MSVCR90.DLL is now in
> system32 -- I still get the "incorrectly linked" error with the: "ruby
> adapter.rb" example.

You should not copy it to system32 either. The ideal solution is to
actually *install* the vcredist package that you have downloaded,
because the installed runtime should go via Windows' WinSxS system.

[Alexey Borzenkov]

On Sat, Jul 18, 2009 at 1:10 PM, will<william....@gmail.com> wrote:
> EvenMachine and Thin gems are BOTH incompatible with the Ruby 1.8 and
> 1.9 run-times, as I see it.  This seems to be a victim of "compiler
> default behaviour".  Binaries compiled with the /MT flag shouldn't
> need either of: MSVCR60.dll and MSVCR90.dll.

Static compiling will not work with languages like Ruby, because then
every extension would have its own copy of C runtime, and memory
wouldn't be safe to allocate/free between them, file handles couldn't
be shared, etc. That's why ruby uses dynamic runtime.

But to be honest with you here, it's actually quite sad that official
Ruby distribution for Windows requires people to use Microsoft Visual
Studio 6.0 to compile extensions. It's pretty expensive and hard to
come by these days, so old it is.

The latest free Visual Studio is however VSExpress 2008, which links
to msvcr90.dll, and which must have been used to compile thin. You
can't expect people to pay lots of money to release something free for
you to use. That's why IMHO it would probably be easier for you to
compile Ruby with VSExpress 2008, or purchase Visual Studio 6.0 and
compile thin yourself.

[rogerdpack]

A follow-up question:
> gem install eventmachine -v0.8.1

Why is this version deeemed to be "more" binary compatible? What
changed after this release?

> The latest free Visual Studio is however VSExpress 2008, which links
> to msvcr90.dll, and which must have been used to compile thin. You
> can't expect people to pay lots of money to release something free for
> you to use. That's why IMHO it would probably be easier for you to
> compile Ruby with VSExpress 2008, or purchase Visual Studio 6.0 and
> compile thin yourself.

you could use a mingw release version of ruby [which comes with its
own compiler if you install the devkit].

http://blog.smajn.net/2009/07/installing-ruby-191-rails-232-and.html
or what not.
Then thin should compile locally as well as EM and it should work.

=r

[will]

Hi gang :-)

I suppose I should be clear. I want a solution that doesn't force
people to go about looking at compiler switches or tear their heads-
off.

rogerdpack>> So is this just a question of compiling
rogerdpack>> the libs with different command line parameters?

More or less, yes -- The reason the GCC (or mingw) compiles work OK is
because they don't have the same MS assumptions with default compile
switches.

The big point here is that neither Ruby 1.8 or Ruby 1.9 "need" ONLY
the


MSVCRT.dll
depends on: KERNEL32.dll
ntdll.dll

and ...

msvcrt-ruby18.dll, or
depends on: KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll
WS2_32.dll
MSVCRT.dll
... or:

msvcrt-ruby191.dll
depends on: KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll
WS2_32.dll
MSVCRT.dll

Libraries to run, as appropriate. I'm not saying these two libraries
are without their own dependencies. My tests today successfully ran
various gem .SO files that are compiled without compiler specific
dependencies. <<shrug>>

MY PERSONAL point to all this is ... it is unnecessary messiness for a
higher-level language like Ruby. One very large reason to work with
Ruby for me, is to skip compile detritus.

Obviously I can do what I need to do with C++ .. I want something that
the users/consumers I write for can USE too. If they have to make C++
builds -- then I need a better solution.


rogerdpack>> you could use a mingw release version of ruby [which
rogerdpack>> comes with its own compiler if you install the
devkit].
rogerdpack>>
rogerdpack>> http://blog.smajn.net/2009/07/installing-ruby-191-rails-232-and.html
rogerdpack>>
rogerdpack>> or what not.
rogerdpack>>
rogerdpack>> Then thin should compile locally as well as EM and it
should work.

I'm sorry team ... I know everyone wants to be "nice" -- Imho, you
can't say the car is working if the first thing a driver needs to do
is change the engine oil, or get on the bus and go to the garage to
buy a new battery and bring it back home to install.

** To save me some time explaining. I'm now making up a nice MS C++
Express 2008
solution file to build projects with "/RUBY configuration" .SO
(libraries) output(s).

My plan is to have a nice little model to make .SO modules manually
because that is going to satisfy my needs for over 10 Gem's that have
incompatible builds. This effort is worth it for me, and for my
purpose.

I popsted because I don't consider that to be a 'smart' move for Ruby
or a nice thing to do to non-C programmers. I would just add one
smaller point too; it is no 'good' feeling that mingw or gnu or
borland or another compiler "disappears" the issue. It won't because
the issue is pervasive, like flooding. Ruby needs a strategy that
satisfies the diverse target for binary release/distributions.

I think building with /MT will make most people happy. (Not me, I've
been at this to long enough to want a build I will be able "to trust"
more. When I see a beginner problem like this I lose confidence in
the process itself. Just me.)


Who knows the discussion may seed some effort to make a binary gem
deployment process. :-)

Aloha
\_w_/



On Jul 18, 9:03 pm, Alexey Borzenkov <sna...@gmail.com> wrote:

> On Sat, Jul 18, 2009 at 1:10 PM, will<william.full.m...@gmail.com> wrote:
> >
> > EvenMachine and Thin gems are BOTH incompatible with the Ruby 1.8 and
> > 1.9 run-times, as I see it.  This seems to be a victim of "compiler
>

> But to be honest with you here, it's actually quite sad that official
> Ruby distribution for Windows requires people to use Microsoft Visual

> ...

> ...

[Alexey Borzenkov]

On Sat, Jul 18, 2009 at 6:29 PM, will<william....@gmail.com> wrote:
> I think building with /MT will make most people happy.  (Not me, I've
> been at this to long enough to want a build I will be able "to trust"
> more.  When I see a beginner problem like this I lose confidence in
> the process itself.  Just me.)

Well, don't get me wrong, but building with /MT is a bad idea, not
only because of more bloat, more heaps, more initialization, but
because you run a risk of freeing something you didn't allocate, or
let other code free something that you allocated, and so on, and so
forth. Of course ruby tries very hard to minimize the risks, by using
its ruby_xmalloc, ruby_xfree, etc, but still it can happen and lead to
very strange things when you least expect it. You can do whatever you
want with extensions you release, but it is scary when people do
whatever they want, how is one supposed to use it in production?

I myself prefer to compile extensions from source, this way I can be
sure that all extensions are tailored for my environment and that they
are compatible. Although the situation with ruby and compilers didn't
look very good to me. I'm very new to ruby, but even in these days I
could notice that extension authors forget to check for /mingw/ along
with /mswin/, rubygems forgets to check C runtime version when
installing binary extensions (which isn't very good for me when I'm
using msvcr90 and it happily installs msvcrt version for me), always
forcing me to use non-existent --platform source.

Yes, ruby-installer based on mingw is a good thing, because now
extension authors may finally notice that there are platforms on
windows other than /mswin/ or /cygwin/. But until it's official and
pushed from ruby-lang I doubt it would revolutionize everything.

Actually I found that cygwin is a lot better than native windows. You
get full posix capabilities, you can compile everything from source,
you get full access to win32 apis (Win32API, Win32OLE, etc.), you
don't need win32-service (and you can install services that actually
work!), and so on and so forth. For ruby and rails developments cygwin
is more suitable, it has all the benefits (with the latest beta cygwin
you can even transparently work with unicode filenames, something you
can't easily do with ruby on win32!) and almost none of drawbacks.

In final words, I'd suggest please, don't start using /MT or anything
crazier. Binary extensions on windows is enough of a mess already, no
need to kill it even further.

[will]

Hi Alexey,

Thanks for your caution. And I quite agree,

a>> "Binary extensions [...] is enough of a mess already"

In fact it is what I've been saying on four list now where binary
builds have fallen afoul of an inconsistent build policy. Just in
case other people are missing the implications of the /MT code
generation, I've pasted in the two help file descriptions for /MD and /
MT.

The /MT is the static run-time lib and adds 52KB to the
Thin_parser-1.1.2.SO file (at 66KB total). The /MD links to the
MSVCR90.DLL.

Yes definitely do NOT go building /MT in gems (just because you can).
However if people don't want to compile everything or just want to
test out a gem to see IF it is what they actually can use, it's an
option.

Gem building people, please figure out how to build to only suck-in
the MSVCRT.dll for your gems if you can. If you can't that's OK it is
status quo. It is worth putting a message in the Gem installer to
point out that there could be a compatibility issue, do we think?

Alexey is quite right there :-)

w.

=========[ ms c++ 2008 help ]=======

/MD
Causes your application to use the multithread- and DLL-specific
version
of the run-time library. Defines _MT and _DLL and causes the
compiler to
place the library name MSVCRT.lib into the .obj file.

Applications compiled with this option are statically linked to
MSVCRT.lib.
This library provides a layer of code that allows the linker to
resolve
external references. The actual working code is contained in
MSVCR90.DLL,
which must be available at run time to applications linked with
MSVCRT.lib.

When /MD is used with the _STATIC_CPPLIB preprocessor definition
(/D_STATIC_CPPLIB),
your application links with the static multithread Standard C++
Library (libcpmt.lib)
instead of the dynamic version (msvcprt.lib), but still links
dynamically to the
main CRT via msvcrt.lib.

Note that the combination of the _STATIC_CPPLIB preprocessor
definition and
the /clr or /clr:pure compiler option is not supported. For more
information
about limitations of the /clr option, see /clr Restrictions.


/MT
Causes your application to use the multithread, static version
of the
run-time library. Defines _MT and causes the compiler to place
the library
name LIBCMT.lib into the .obj file so that the linker will use
LIBCMT.lib to
resolve external symbols.

On Jul 19, 2:38 am, Alexey Borzenkov <sna...@gmail.com> wrote:
>
> In final words, I'd suggest please, don't start using /MT or anything
> crazier. Binary extensions on windows is enough of a mess already, no
> need to kill it even further.

[James Tucker]

On 19 Jul 2009, at 08:01, will wrote:

>
> Hi Alexey,

It'd be good to have Luis Lavena weigh in on this. He's done a lot of
thinking on the topic.

> Thanks for your caution. And I quite agree,
>
> a>> "Binary extensions [...] is enough of a mess already"
>
> In fact it is what I've been saying on four list now where binary
> builds have fallen afoul of an inconsistent build policy. Just in
> case other people are missing the implications of the /MT code
> generation, I've pasted in the two help file descriptions for /MD
> and /
> MT.
>
> The /MT is the static run-time lib and adds 52KB to the
> Thin_parser-1.1.2.SO file (at 66KB total).

This is fine, but basically irrelevant. It doesn't solve the actual
edge case issues introduced by mixed runtimes, which is passing
incompatible struct definitions and whatnot.

> The /MD links to the
> MSVCR90.DLL.

This is a problem, unless you build everything linked to that runtime.

> Yes definitely do NOT go building /MT in gems (just because you can).
> However if people don't want to compile everything or just want to
> test out a gem to see IF it is what they actually can use, it's an
> option.

RubyGems has supported this for a *long* time, but releases are never
properly handled. There is a platform extension to gems so that you
can select down to the specific compatible version. e.g.

thin-1.2.0-x86-mswin-90.gem

>
> Gem building people, please figure out how to build to only suck-in
> the MSVCRT.dll for your gems if you can. If you can't that's OK it is
> status quo. It is worth putting a message in the Gem installer to
> point out that there could be a compatibility issue, do we think?

The standard Luis is using and I strongly agree with is that we should
continue to use msvcrt 6, and that the preferred method for open
source binary builds is mingw. There are some very good articles on
this, and rake-compiler provides significant assistance. The 1.9 vs.
1.8 problem is still something that I think rubygems has scope for
helping with, but the team are generally busy.

> Alexey is quite right there :-)

wrt. cygwin, I considering cygwin to be a completely seperate
environment. It's not windows, it's not posix (really), and it's not
unix. It is close to all three. Cygwin builds should be properly
platformed as previously described.

[will]

Hi James,

Nice to see you again. I want to clear-up one point. I want to NOT
link MSVCRT90.

On Jul 20, 9:09 pm, James Tucker <jftuc...@gmail.com> wrote:
>
> RubyGems has supported this for a *long* time, but releases are never  
> properly handled. There is a platform extension to gems so that you  
> can select down to the specific compatible version. e.g.
>
> thin-1.2.0-x86-mswin-90.gem

I'd liked to have had a thin-1.2.0-x86-mswin.gem for the pre-2008
compiler.

In my opinion, faced with this kind of situation, the smart thing to
do is to make a Ruby-runtime.lib that gem builds link to (via the
rbconfig.rb file) == And not link to the locally installed Microsoft
default library. Now, that I think about it ... Such a Ruby-
runtime.DLL layer cold "choose" the most modern run-time with a little
thought. I imagine that's not worth it with 1.9 coming along.

This would also meant that developers can add low-level stuff with
quite a lot of stability and predictability. I am interested in the
Ruby-level side of the language. It doesn't mean I've forgotten years
and year of C++ stuff across a variety of platforms, compilers and
architectures.

Thanks and regards,

Will.

[James Tucker]

On 21 Jul 2009, at 11:03, will wrote:

>
> Hi James,
>
> Nice to see you again. I want to clear-up one point. I want to NOT
> link MSVCRT90.

Then don't use that compiler.

>
> On Jul 20, 9:09 pm, James Tucker <jftuc...@gmail.com> wrote:
>>
>> RubyGems has supported this for a *long* time, but releases are never
>> properly handled. There is a platform extension to gems so that you
>> can select down to the specific compatible version. e.g.
>>
>> thin-1.2.0-x86-mswin-90.gem
>
> I'd liked to have had a thin-1.2.0-x86-mswin.gem for the pre-2008
> compiler.
>
> In my opinion, faced with this kind of situation, the smart thing to
> do is to make a Ruby-runtime.lib that gem builds link to (via the
> rbconfig.rb file) == And not link to the locally installed Microsoft
> default library. Now, that I think about it ... Such a Ruby-
> runtime.DLL layer cold "choose" the most modern run-time with a little
> thought. I imagine that's not worth it with 1.9 coming along.

How would you actually achieve this? AFAIK, with the Microsoft
compilers at least, you can't do this?

The gem is no longer properly managed, check the output of `gem list -
a -r -d thin`:
thin (1.2.2, 1.2.1, 1.0.0, 0.8.2, 0.8.1, 0.8.0, 0.7.1, 0.7.0, 0.6.4,
0.6.3, 0.6.2, 0.6.1, 0.6.0, 0.5.4, 0.5.3, 0.5.2, 0.5.0, 0.4.1, 0.4.0,
0.3.0)
Platforms:
0.3.0: ruby
0.4.0: ruby
0.4.1: ruby
0.5.0: ruby
0.5.2: ruby
0.5.3: ruby, x86-mswin32-60
0.5.4: ruby, x86-mswin32-60
0.6.0: ruby, x86-mswin32-60
0.6.1: ruby, x86-mswin32-60
0.6.2: ruby, x86-mswin32-60
0.6.3: ruby, x86-mswin32-60
0.6.4: ruby, x86-mswin32-60
0.7.0: ruby, x86-mswin32-60
0.7.1: ruby, x86-mswin32-60
0.8.0: i386-mswin32, ruby
0.8.1: i386-mswin32, ruby
0.8.2: i386-mswin32, ruby
1.0.0: i386-mswin32, ruby
1.2.1: i386-mswin32, ruby
1.2.2: ruby
Author: Marc-Andre Cournoyer
Rubyforge: http://rubyforge.org/projects/thin
Homepage: http://code.macournoyer.com/thin/

As of 0.8.0 the windows builds are dodgy.

EventMachine is correct since Aman Gupta has been doing releases:

eventmachine (0.12.8, 0.12.6, 0.12.4, 0.12.2, 0.12.0, 0.10.0, 0.9.0,
0.8.1, 0.8.0, 0.7.2, 0.7.0, 0.5.3, 0.5.2, 0.5.1, 0.4.5, 0.4.4, 0.4.3,
0.4.2, 0.4.0, 0.3.1)
Platforms:
0.3.1: ruby
0.4.0: ruby
0.4.2: ruby
0.4.3: ruby
0.4.4: ruby
0.4.5: ruby
0.5.1: ruby
0.5.2: ruby
0.5.3: ruby
0.7.0: ruby
0.7.2: ruby
0.8.0: ruby
0.8.1: i386-mswin32, ruby
0.9.0: ruby
0.10.0: ruby
0.12.0: i386-mswin32, ruby
0.12.2: ruby
0.12.4: ruby
0.12.6: java, ruby, x86-mswin32-60
0.12.8: java, ruby, x86-mswin32-60
Author: Francis Cianfrocca
Rubyforge: http://rubyforge.org/projects/eventmachine
Homepage: http://rubyeventmachine.com

> This would also meant that developers can add low-level stuff with
> quite a lot of stability and predictability. I am interested in the
> Ruby-level side of the language. It doesn't mean I've forgotten years
> and year of C++ stuff across a variety of platforms, compilers and
> architectures.

If you know of some magic solution to this problem whereby you can
selectively link as you wish, as opposed to the way VS says you
should, then please, explain. It's not just ruby that needs this, but
python, perl, openssl, postgresql, etc, etc, etc.

As far as moving forward is concerned, Windows users developing ruby
should do one of two things:

1) install a compiler environment, and build the entire stack,
possibly run your own gemserver with well platformed binary gems.
(gem_repackager is an unfinished hack around trying to solve this
problem slightly more easily, works ok joined to a CI system)
2) use exclusively mscvrt6 linked builds. generally speaking gem
authors should not link other C runtimes on win32, but ofc, that's
wishful thinking. If they have linked another runtime, you need to
rebuild.

There are outstanding issues, still. In particular mingw cannot build
against SEH, and this is a problem for win32-api and friends. At
present I use a mostly mingw stack, with precompiled x86-mswin32-60
builds of the win32 gems.

>
> Thanks and regards,
>
> Will.
>
> >

[Luis Lavena]

On Jul 21, 7:03 am, will <william.full.m...@gmail.com> wrote:
> Hi James,
>

Hello Guys, I love to chime in...

> Nice to see you again.  I want to clear-up one point.  I want to NOT
> link MSVCRT90.
>

Then do not use VC8 (MSVCR80.dll) or VC9 (MSVCR90.dll)

There is no library for linking back to MSVCRT.dll.

MinGW compiler set is the only able to link against different versions
of MSVCRT.

> On Jul 20, 9:09 pm, James Tucker <jftuc...@gmail.com> wrote:
>
>
>
> > RubyGems has supported this for a *long* time, but releases are never  
> > properly handled. There is a platform extension to gems so that you  
> > can select down to the specific compatible version. e.g.
>
> > thin-1.2.0-x86-mswin-90.gem
>
> I'd liked to have had a thin-1.2.0-x86-mswin.gem for the pre-2008
> compiler.
>
> In my opinion, faced with this kind of situation, the smart thing to
> do is to make a Ruby-runtime.lib that gem builds link to (via the
> rbconfig.rb file) == And not link to the locally installed Microsoft
> default library.  Now, that I think about it ... Such a Ruby-
> runtime.DLL layer cold "choose" the most modern run-time with a little
> thought.  I imagine that's not worth it with 1.9 coming along.
>

Don't get my wrong, but that is a bad idea.

This raised several times at Ruby-core, and Core rejected it due the
complexity involved.

Perl did it's own runtime library to support the mix of CRT, and
didn't worked very well (besides the penalty overhead and the
complexity of maintaining it).

> This would also meant that developers can add low-level stuff with
> quite a lot of stability and predictability.  I am interested in the
> Ruby-level side of the language.  It doesn't mean I've forgotten years
> and year of C++ stuff across a variety of platforms, compilers and
> architectures.

Well, switching to MinGW and rake-compiler can take all that pain
you're suffering or you feel is stressing out the beauty of the Ruby
language.

I've invested quite some time to investigate and work on solutions to
build a better and improved platform for Ruby on Windows.

--
Luis Lavena

[James Tucker]

On 21 Jul 2009, at 14:09, Luis Lavena wrote:

>
> On Jul 21, 7:03 am, will <william.full.m...@gmail.com> wrote:
>> Hi James,
>>
>
> Hello Guys, I love to chime in...

Welcome and thx, <3

[rogerdpack]

So does compiling without the
/MD
fix the problem? It should be "binary compatible" as long as it calls
into ruby calls [1].
=r
http://programming-gone-awry.blogspot.com/2009/07/how-to-compile-using-visual-studio-for.html

[James Tucker]

Oh boy....

[Luis Lavena]

On Jul 24, 4:46 am, James Tucker <jftuc...@gmail.com> wrote:
> Oh boy....
>

Tell me about it.

Mixing compilers and playing with libraries that do not use xfree to
release memory is going to be a nightmare.

The dll is not picking the manifest because RbConfig do not include
instructions to do so.

You need to change rbconfig.rb to be able to build with VC8/9.

--
Luis Lavena

[Jon]

On Jul 24, 2:15 pm, Luis Lavena <luislav...@gmail.com> wrote:
> The dll is not picking the manifest because RbConfig do not include
> instructions to do so.
>
> You need to change rbconfig.rb to be able to build with VC8/9.

Luis, what precisely needs to change in rbconfig.rb?


On a related note...

...as I've been fighting to get up to speed by reading "Building
Windows Native Ruby Extensions: How Not to Harm Yourself or Others", I
keep wondering if rbconfig.rb had something like

CONFIG["RUBY_CORE_CRT"] = "msvcrt"

whether many of our downstream build and pkg mgmt tools (make, rake-
compiler, hoe, gem, etc) could more easily solve the dont-mix-c-
runtimes issue (and others) in that they would know the CRT used to
build Ruby core and could link appropriately. This info should be
known in advance when one builds Ruby, right?

My current understanding is that this wouldn't be a big help with the
MS tool chains as you *can't* pick a specific CRT (correct?) to link
against, but for any of the GCC-based tools this could be a big help
as you can specify.

Would this help with thin, eventmachine, and others on Windows...or is
it a red herring?

Jon

[Luis Lavena]

On Jul 28, 2:17 pm, Jon <jon.for...@gmail.com> wrote:
> On Jul 24, 2:15 pm, Luis Lavena <luislav...@gmail.com> wrote:
>
> > The dll is not picking the manifest because RbConfig do not include
> > instructions to do so.
>
> > You need to change rbconfig.rb to be able to build with VC8/9.
>
> Luis, what precisely needs to change in rbconfig.rb?
>

The linking switches and commands to embed the manifest inside the DLL
that will trigger the SxS assemblies to load MSVCR90.dll

Also the compiling flags and optimization ones, plus definitions to
avoid warnings due "insecure" CRT calls like sprintf.

> On a related note...
>
> ...as I've been fighting to get up to speed by reading "Building
> Windows Native Ruby Extensions: How Not to Harm Yourself or Others", I
> keep wondering if rbconfig.rb had something like
>
> CONFIG["RUBY_CORE_CRT"] = "msvcrt"
>

No, you have sitearch, but that prepends the Ruby version.

This thing with the different CRT has been going on at Ruby-core since
I have memory.

> whether many of our downstream build and pkg mgmt tools (make, rake-
> compiler, hoe, gem, etc) could more easily solve the dont-mix-c-
> runtimes issue (and others) in that they would know the CRT used to
> build Ruby core and could link appropriately.  This info should be
> known in advance when one builds Ruby, right?
>

That is something like disttools form Python in Ruby.

That requires complete rewrite on how mkmf works, which I can tell is
a really daunting task!

> My current understanding is that this wouldn't be a big help with the
> MS tool chains as you *can't* pick a specific CRT (correct?) to link
> against, but for any of the GCC-based tools this could be a big help
> as you can specify.

Yes, MS tools cannot change the CRT, and GCC can. Basically tweaking
RbConfig::CONFIG['LIBRUBYARG_SHARED'] and friends can work.

But then, is cheating.

> Would this help with thin, eventmachine, and others on Windows...or is
> it a red herring?

Sorry to say this but is like using ducktape to avoid the window of
the space shuttle to fall off the frame.

The problem is the mixing of compilers.

VC6 Ruby cannot be used in conjunction with VC8 or VC9.

The safest bet, with a bit or small work is change how thin and event
machine are built to make them work with Rake-compiler.

To my bad I cannot commit to the task, but I'm available to questions
about it.

Cheers,

--
Luis Lavena

[rogerdpack]

> Luis, what precisely needs to change in rbconfig.rb?

Maybe you just need to take the /MD out of whatever Config has the /MD
in it?

> The problem is the mixing of compilers.
>
> VC6 Ruby cannot be used in conjunction with VC8 or VC9.

Well theoretically it could, as long as all binaries use xfree instead
of free :) [scary].

> The safest bet, with a bit or small work is change how thin and event
> machine are built to make them work with Rake-compiler.

I agree.

Sorry I can't help much either since I'm too lazy to install anything
but mingw.
Note that you can install your own mingw if desired [clone the one
click from github, run rake]
=r