Mongrel doesn't start under Rails 2.0.2/Win XP

All,

Mongrel 1.1.3
Rails 2.0.2
Ruby 1.8.6
Windows XP SP2

When I issue the command “ruby script/server” from any of my Rails
projects on v. 2.0.2, I get a Windows dialog with the error:

“The application has failed to start because MSVCR80.dll was not found.
Re-installing the application may fix this problem.”

I’ve gone through the process of attempting to introduce MSVCR80.dll
into my PATH but just generate more errors.

I suspect that at some point, the precompiled Mongrel gem started
getting compiled with a newer version of the MS C compiler than my
runtime supports. I have the Windows Platform SDK for Windows Server
2003 R2 installed.

Does anyone know if the runtime support for Mongrel has changed in the
last few revs.? Or is my theory completely wack?

Thanks,
Wes G.

Wes, are your using RMagick 2.0 or above? I ask because I noticed in the
release notes recently that it was compiled with VC 8 (2005). Perhaps
this is the problem?

Current resolution:

Rolled back to Mongrel 1.1 and I can run it.

The original error (w/Mongrel 1.1.3) was a Windows dialog that displayed
"“The application has failed to start because MSVCR80.dll was not found.
Re-installing the application may fix this problem.” When I would click
on that dialog’s OK button, it would pop up again and I would never be
able to get past the error.

This behavior appears for Mongrel versions >= 1.1.1.

At 1.1, I get the error dialog once, click the OK button and Mongrel
proceeds to start up.

Wes

On Jan 11, 2008 6:00 AM, Wes G. [email protected] wrote:

Current resolution:

Rolled back to Mongrel 1.1 and I can run it.

But again, you’re using RMagick 2.0?

It seems you’re missing the VC8 C runtimes, and later versions of
Mongrel fire the requirement.

Try this on irb:
require ‘rubygems’
require ‘mongrel’

And you will see there is no problem with that.

Anyway, script/server is something weird, if you try “mongrel_rails
start” you will see there is no problem.

Again, you have some extension that is linked with MSVCR80.dll, and
since is RMagick, that could bring a series of problems in relation to
malloc and free.

Don’t blame us we didnt’ warn you :slight_smile:


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

Could this be a rubygems issue? I constantly get gems installing the
ruby version instead of the win32 version just because it can. If you
uninstall and re-install, does it say it is compiling? If so, you
would need to have VC6 set as your default compiler in Windows.

On Jan 11, 2008 9:40 AM, Wes G. [email protected] wrote:

Thanks,
Wes


Posted via http://www.ruby-forum.com/.


Mongrel-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/mongrel-users


Cheers,

Kevin W.
http://www.bantamtech.com/

Luis,

I do not have RMagick installed at all.

I see the same exact behavior that I described above if I start mongrel
using “mongrel_rails start”.

I also see that same behavior if I go into irb and issue the “require
rubygems” and “require mongrel” commands.

Thanks,
Wes

On Jan 11, 2008 4:51 PM, Kevin W. [email protected] wrote:

Could this be a rubygems issue? I constantly get gems installing the
ruby version instead of the win32 version just because it can. If you
uninstall and re-install, does it say it is compiling? If so, you
would need to have VC6 set as your default compiler in Windows.

Will be more helpful if you provide us with the versions of ruby.

Anyway, if you’re getting that MSVCR80.dll is missing, that means that
something is getting loaded and it is reaquiring that missing library.

That could be because you installed a gem that was build with VC8
(which is not the same as the One-Click Installer, in case you used
it).

Please, provide more background information.

Can you provide your RUBY_PLATFORM and Ruby version?
ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]

ruby -e “puts RUBY_PLATFORM”
i386-mswin32

I can bet that you have i386-mswin32_80 as platform, since rubygems is
switching to pure ruby gems instead of pre compiled ones.


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

Hello. I’m new to this list as of this week.
I am supporting a Win2k3Server installation of RoR. I’m not very
familiar
with what you guys are discussing but I did have a very similar error
occuring earlier in the week. I had just installed Ruby for IIS version
0.1(
http://rubyforiis.sosukodo.org/rubyforiis/). For some reason it stepped
on
this dll during the install. After realizing it would be very stupid to
try
to support RoR on IIS, I uninstalled this software and the error
magically
disappeared. I have no further explanation for what happened.
Hope this helps.

Luis L. wrote:

Will be more helpful if you provide us with the versions of ruby.

Luis,

Here is my version information.

C:\eclipse\workspace>ruby -v
ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]

C:\eclipse\workspace>ruby -e “puts RUBY_PLATFORM”
i386-mswin32

C:\eclipse\workspace>gem --version
1.0.1

C:\eclipse\workspace>gem list mongrel

*** LOCAL GEMS ***

mongrel (1.1)
mongrel_cluster (1.0.5)
mongrel_service (0.3.4)

Also, I have successfully installed C-based gems under the new rubygems
regime of wanting to compile - AFAIK, my C environment is set up
correctly for this. However, installing the mongrel gem has never
kicked off a compile, so I’m getting pre-compiled gems.

Wes

On Jan 11, 2008 5:49 PM, Wes G. [email protected] wrote:

1.0.1

C:\eclipse\workspace>gem list mongrel

*** LOCAL GEMS ***

mongrel (1.1)
mongrel_cluster (1.0.5)
mongrel_service (0.3.4)

Ok, it seems I lost my bet.

But the “missing MSVCR80.dll” error is because some extension is
linked with it, and your application is loading it.

You can install the Microsoft Redistributable C runtime 8.0 and maybe
that will solve the error message.

Also, I have successfully installed C-based gems under the new rubygems
regime of wanting to compile - AFAIK, my C environment is set up
correctly for this. However, installing the mongrel gem has never
kicked off a compile, so I’m getting pre-compiled gems.

Yes, that version of ruby will get proper, existing compiled gems
installed.

Can you provide the whole list of gems you have installed?

Also, you’re using One-Click Installer, InstantRails or Bitnami?


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

On Jan 11, 2008 5:28 PM, Stephen C [email protected] wrote:

Hello. I’m new to this list as of this week.
I am supporting a Win2k3Server installation of RoR. I’m not very familiar
with what you guys are discussing but I did have a very similar error
occuring earlier in the week. I had just installed Ruby for IIS version 0.1
(http://rubyforiis.sosukodo.org/rubyforiis/). For some reason it stepped on
this dll during the install. After realizing it would be very stupid to try
to support RoR on IIS, I uninstalled this software and the error magically
disappeared. I have no further explanation for what happened.
Hope this helps.

RubyForIIS have two problems:

Is outdated.
Is compiled with VC8, which is not compatible with One-Click Installer
(VC6).

Part of RubyForIIS is libfcgi and ruby-fcgi, which could be getting
loaded and thus, failing with missing dll.


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

I installed with One-Click about 2 months ago.

Here are my gems (don’t make fun at how I have like almost every version
of rails :]):

C:\eclipse\workspace\credentials>gem list

*** LOCAL GEMS ***

actionmailer (2.0.2, 2.0.1, 1.3.6, 1.3.5, 1.3.4, 1.3.3, 1.2.5)
actionpack (2.0.2, 2.0.1, 1.13.6, 1.13.5, 1.13.4, 1.13.3, 1.12.5)
actionwebservice (1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.1.6)
activerecord (2.0.2, 2.0.1, 1.15.6, 1.15.5, 1.15.4, 1.15.3, 1.14.4)
activeresource (2.0.2)
activesupport (2.0.2, 2.0.1, 1.4.4, 1.4.3, 1.4.2, 1.3.1)
appcelerator (2.0.2)
capistrano (2.1.0, 2.0.0, 1.4.1)
cgi_multipart_eof_fix (2.5.0)
fastercsv (1.2.3)
fastthread (1.0.1)
fit (1.1)
fxri (0.3.6)
fxruby (1.6.13)
gem_plugin (0.2.3)
highline (1.4.0)
hoe (1.4.0)
hpricot (0.6)
htmlentities (4.0.0)
htmltools (1.10)
image_science (1.1.3)
json (1.1.2)
log4r (1.0.5)
mocha (0.5.6)
mongrel (1.1)
mongrel_cluster (1.0.5)
mongrel_service (0.3.4)
mysql (2.7.3)
needle (1.3.0)
net-sftp (1.1.0)
net-ssh (1.1.2)
rails (2.0.2, 2.0.1, 1.2.6, 1.2.5, 1.2.4, 1.2.3, 1.1.6)
railsbench (0.9.2)
rake (0.8.1)
rcov (0.8.1.2.0)
RedCloth (3.0.4)
redgreen (1.2.2)
rjb (1.1.1)
ropenlaszlo (0.4.1)
ruby-debug (0.10.0)
ruby-debug-base (0.10.0)
ruby-snarl (0.0.8)
rubyforge (0.4.4)
rubygems-update (1.0.1)
RubyInline (3.6.6)
rubyzip (0.9.1)
sources (0.0.1)
tattle (1.0.3)
text-format (1.0.0)
text-hyphen (1.0.0)
tzinfo (0.3.6)
watir (1.5.3)
win32-api (1.0.5)
win32-clipboard (0.4.3)
win32-dir (0.3.2)
win32-eventlog (0.4.7)
win32-file (0.5.5)
win32-file-stat (1.2.7)
win32-process (0.5.5)
win32-sapi (0.1.4)
win32-service (0.6.1, 0.5.2)
win32-sound (0.4.1)
win32console (1.0.8)
windows-api (0.2.0)
windows-pr (0.7.4)
ZenTest (3.7.2)

Some more information:

(* using mongrel_rails start to startup *)

Mongrel v. 0.3.13.3: No error dialog on startup
Mongrel v. 1.0 - 1.1: Error dialog, click OK, mongrel proceeds
Mongrel v >= 1.1.1: Error dialog, click OK, error dialog reappears, no
further progress can be made.

All I have to do is modify Mongrel versions to get these behaviors.

Does anyone know if MSVCR80.DLL is a standard part of the Microsoft
Platform SDK for Windows Server 2003 R2 distribution? If so, then the
implication is I screwed up the installation somehow.

What is the latest correct version of the Windows SDK on Windows XP SP2?
I may just try to move to that (although I’m trying to avoid that - I
will be forsaking the Windows platform for a MacBookPro as soon as they
announce the new models).

Wes

On Jan 12, 2008 12:37 AM, Will G. [email protected] wrote:

Is nmake in your path? If so, from your comments, it appears that
some of your gem installs ARE compiling gems with whatever Platform
SDK you have installed (looks like its Server 2003).

Oh, I think I overlooked at the comments done in this thread…

Yeah: if oyu have VC8/9 and Platform SDK in the Path, any gem that
output “Building native extension” legend during installation will
show up some serious problems.

Luis can explain far better than I, but gems compiled with VC 8 are NOT
compatible with the One Click installer (which is compiled with VC 6).
Sure, they might run, but they’ll lead to trouble.

Yep. Exactly.

I’ll suggest you install a clean version of One-Click Installer
(latest is 1.8.6-26) and then install your gems in a clean
environment.

Ensure first you don’t have nmake or cl in your path. That will avoid
gems being compiled with VC8.

Anyway, if you had installed both VC8 and Platform SDK, you shouldn’t
see the missing runtime… unless you have some gem that wasn’t
compiled properly (which is possible).

I’ve found this to be the most stable mix (short of buying a
Mac or installing Linux).

A mac is expensive, and will not remove the whole pain of using
Ruby… check some of the Leopard nightmares around the web :wink:

HTH,

Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

I’ll suggest you install a clean version of One-Click Installer
(latest is 1.8.6-26) and then install your gems in a clean
environment.

Ensure first you don’t have nmake or cl in your path. That will avoid
gems being compiled with VC8.

This is kind of funny, because when rubygems 0.9.5 came out, it appeared
that I was now required to compile native gems on Windows and that is
when I finally made sure that nmake would work to completion and
actually compile stuff. It sounds like you’re saying that I should have
waited for the pre-compiled gems to get fixed :).

A mac is expensive, and will not remove the whole pain of using
Ruby… check some of the Leopard nightmares around the web :wink:

It’s true. But given that, in my experience, many gem and plugin
developers test little to not at all on Windows, the Mac is the
“platform of least surprise”. Although I’ve been able to solve all of
my Windows-specific Ruby issues eventually, I am just tired of having to
spend time and energy doing that.

Wes

On Jan 12, 2008 3:48 PM, Wes G. [email protected] wrote:

when I finally made sure that nmake would work to completion and
actually compile stuff. It sounds like you’re saying that I should have
waited for the pre-compiled gems to get fixed :).

Oh, no!

Please try upgrading rubygems to 1.0.1!!!

0.9.5 is broken for us (Windows users)!

I posted this a way back when Rails guys did the 2.dot Oh release:

http://blog.mmediasys.com/2007/12/19/latest-rubygems-and-rails-is-a-deadly-combo/

I worked a few hours with Eric H. getting this fixed before rubygems
1.0…

Please, update to it and the pain will go away :smiley:

A mac is expensive, and will not remove the whole pain of using
Ruby… check some of the Leopard nightmares around the web :wink:

It’s true. But given that, in my experience, many gem and plugin
developers test little to not at all on Windows, the Mac is the
“platform of least surprise”. Although I’ve been able to solve all of
my Windows-specific Ruby issues eventually, I am just tired of having to
spend time and energy doing that.

“of least surprise” … right :slight_smile:

I also like the “think different” motto and the just offer 2 (or one)
option to “be different”. If you don’t do it “the mac way”, then you
should die… :stuck_out_tongue:


Luis L.
Multimedia systems

A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

Is nmake in your path? If so, from your comments, it appears that
some of your gem installs ARE compiling gems with whatever Platform
SDK you have installed (looks like its Server 2003).

Luis can explain far better than I, but gems compiled with VC 8 are NOT
compatible with the One Click installer (which is compiled with VC 6).
Sure, they might run, but they’ll lead to trouble.

If you want to continue down this path, then the quickest way to get rid
of the error messages you get is to install the VC 8 Runtime
Redistributable. Don’t count on a stable system, though.

I feel your pain here. I develop mostly on Vista notebook. I keep both
the OCI and Cygwin’s Ruby around. They both have their strengths and
weaknesses, but until Ruby can be made to compile and function reliably
with VC 8, I’ve found this to be the most stable mix (short of buying a
Mac or installing Linux).

==
Will G.

Based on my testing, it appears to me there is something that Mongrel is
loading that is requiring MSVCR80.dll, since 1.0. Isn’t that correct?

Oh, no!

Please try upgrading rubygems to 1.0.1!!!

0.9.5 is broken for us (Windows users)!

I’ve been on 1.0.1 for a while. I’m on the rubygems-developers list so
I see as soon as they post updates and I tend to upgrade immediately.
So I ran into all the 0.9.5 problems and to try and fix it, I got my
gems to compile on Windows. But I’ve been off of 0.9.5 for a while.

I also like the “think different” motto and the just offer 2 (or one)
option to “be different”. If you don’t do it “the mac way”, then you
should die… :stuck_out_tongue:

I know. Honestly, I’ve enjoyed the “underdog” role of being “the only
or one of few Windows guys in the room” at Ruby/Rails gathering to some
degree. And when I get the sense that there is Mac elitism at work, it
really bugs me. But, if I’m going to use Rails as a major tool in my
work, it behooves me to make it as easy as possible for myself to
develop. Back when I was doing mostly Java work, it didn’t really
matter that I was on Windows.

Wes

Given all this, I’m starting to entertain using JRuby. It ships with
NetBeans, and we know that we can compile with Java successfully…

==
Will G.

On Jan 12, 2008 10:48 AM, Wes G. [email protected] wrote:

This is kind of funny, because when rubygems 0.9.5 came out, it appeared
that I was now required to compile native gems on Windows and that is
when I finally made sure that nmake would work to completion and
actually compile stuff. It sounds like you’re saying that I should have
waited for the pre-compiled gems to get fixed :).

I had the same concern when 0.9.5 came out. I think what was missed
was the fact that only compiling with VC++6 would be safe with the OCI
installation. If you have VC++6 and nmake is compiling gems for you,
you should be fine. Or, make sure you’re not compiling gems. That’s my
approach, at least.


Cheers,

Kevin W.
http://www.bantamtech.com/