Gem install fcgi

[Tony Targonski]

Gem installation of fcgi appears to be broken

____
Building native extensions. This could take a while...
ERROR: While executing gem ... (RuntimeError)
ERROR: Failed to build gem native extension.
Gem files will remain installed in
c:/ruby/lib/ruby/gems/1.8/gems/fcgi-0.8.5 for
inspection.
ruby extconf.rb install fcgi\nchecking for fcgiapp.h... no

Results logged to c:/ruby/lib/ruby/gems/1.8/gems/fcgi-0.8.5/gem_make.out
`````

Is there another way to get this installed?
--Tony

 

[Thursday]

Gem installation of fcgi appears to be broken

____
Building native extensions. This could take a while...
ERROR: While executing gem ... (RuntimeError)
ERROR: Failed to build gem native extension.
Gem files will remain installed in
c:/ruby/lib/ruby/gems/1.8/gems/fcgi-0.8.5 for
inspection.
ruby extconf.rb install fcgi\nchecking for fcgiapp.h... no

Results logged to c:/ruby/lib/ruby/gems/1.8/gems/fcgi-0.8.5/gem_make.out
`````

Is there another way to get this installed?
--Tony

I just noticed fcgi-0.8.6 was made available with important bugfixes.
It was checked into Debian unstable very recently.

Not sure but maybe the gem is/was being updated when you tried?

 

[Aredridel]

Gem installation of fcgi appears to be broken

Building native extensions. This could take a while...
ERROR: While executing gem ... (RuntimeError)
ERROR: Failed to build gem native extension.
Gem files will remain installed in
c:/ruby/lib/ruby/gems/1.8/gems/fcgi-0.8.5 for
inspection.
ruby extconf.rb install fcgi\nchecking for fcgiapp.h... no

Do you have the fastcgi development kit installed?

 

[Chad Fowler]

Do you have the fastcgi development kit installed?

It definitely looks like it's not installed. Being on Windows, you
will also need a compiler to be in the path, since this is a source
extension gem.

--

Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 100,000 gems served!)

 

[Aredridel]

It definitely looks like it's not installed. Being on Windows, you
will also need a compiler to be in the path, since this is a source
extension gem.

I suppose the gem can't fall back to the pure ruby version? (Can gems
do this at all?)

 

[Tobias Luetke]

There is no gem for the new fcgi release. Can anyone help out? Tom?
This is very very important because of the recent popularity of rails.
Memory leaks in the suggested production setup are not cool.

Also I think fcgi should get a version bump to 1.0 . Version numbers
like 0.8.6 are just confusingly smelling like beta software. There are
several companies (37signals, snowdevil...) futures being trusted to
this code so I really think it deserves the production ready tag

 

[Chad Fowler]

I suppose the gem can't fall back to the pure ruby version? (Can gems
do this at all?)

No, but that's a really neat idea!

--

Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 100,000 gems served!)

 

[Pat Maddox]

I was getting that error too, but on FreeBSD. Opted just to install
ruby-fcgi from ports instead, worked fine.

 

[Aredridel]

There is no gem for the new fcgi release. Can anyone help out? Tom?
This is very very important because of the recent popularity of rails.
Memory leaks in the suggested production setup are not cool.

Also I think fcgi should get a version bump to 1.0 . Version numbers
like 0.8.6 are just confusingly smelling like beta software. There are
several companies (37signals, snowdevil...) futures being trusted to
this code so I really think it deserves the production ready tag

Let me suggest something. The best mark of "production ready" is to look
at the source and judge for yourself, or test and get usage data. One's
beta is another's release quality. And more eyes on the code and actual
-reports- from operational experience help a lot.

Kirk is using FastCGI with Enigo, and I know that 37 signals is using it
too -- that's where two of the last bug-fixes started life. More
reports are a good thing -- even if it's just "I'm using it with ____
kinds of loads for ___" are the real mark of confidence.

While 1.0 might be nice, It would be even better to have publically
visible input on its stability. That goes for all software, in my
opinion. Actual usage is the best claim to stability, not a claimed
version number. There's no race to 1.0, since the next thing after that
is 1.1 to fix its bugs, of course. It's an ongoing process. The real
trick is to know it works for others in your situation, and when.

Since I'm using FastCGI in a production environment, and will admit to
starting the "use lighttpd!" trend, I've a vested interest in making it
work right. Let's get some declarations of problems and declarations of
success out in public and make ruby-fcgi some trusted software that way,
and let's uncover any remaining bug there might be.

Ari

 

[Paul Hanchett]

I just noticed fcgi-0.8.6 was made available with important bugfixes. It
was checked into Debian unstable very recently.

Not sure but maybe the gem is/was being updated when you tried?

I get the same error, but it pretty much always happens to me for
anything that builds a "native extension". Wish I knew how to fix it.

 

[Aredridel]

Not sure but maybe the gem is/was being updated when you tried?

I get the same error, but it pretty much always happens to me for
anything that builds a "native extension". Wish I knew how to fix it.

You'll need a compatible compiler in your path.

 

[Thursday]

Let me suggest something. The best mark of "production ready" is to look
at the source and judge for yourself, or test and get usage data. One's
beta is another's release quality. And more eyes on the code and actual
-reports- from operational experience help a lot.

Kirk is using FastCGI with Enigo, and I know that 37 signals is using it
too -- that's where two of the last bug-fixes started life. More
reports are a good thing -- even if it's just "I'm using it with ____
kinds of loads for ___" are the real mark of confidence.

While 1.0 might be nice, It would be even better to have publically
visible input on its stability. That goes for all software, in my
opinion. Actual usage is the best claim to stability, not a claimed
version number. There's no race to 1.0, since the next thing after that
is 1.1 to fix its bugs, of course. It's an ongoing process. The real
trick is to know it works for others in your situation, and when.

Since I'm using FastCGI in a production environment, and will admit to
starting the "use lighttpd!" trend, I've a vested interest in making it
work right. Let's get some declarations of problems and declarations of
success out in public and make ruby-fcgi some trusted software that way,
and let's uncover any remaining bug there might be.

Ari

In principal, I agree with you 100%. But this world is full of people
that make technology decisions based on PERCEPTION or outdated policies
rather than technical merit or common sense.

Sadly, we live in a world where MANY companies do not allow ANY software
with a version number <= 1.0 to be installed on their hardware. They
won't allow 1.0 so advocating 0.x software is akin to getting an "I'm an
irresponsible & reckless employee" tatooed on one's forehead. Not
exactly the smart thing to do when an Indian with a masters degree in
Comp Sci can do your job at 1/10th your salary these days without
advocating 0.x software.

I know of one company that wouldn't allow Apache 1.3 to replace IIS 4.0
solely on the basis of IT policy not allowing software with version 1.x
to be installed.

So while I agree with you in principal, I think fcgi going 1.0, 1.1 or
2.1 (better still) would make it SUBSTANTIALLY easier to convince many
companies to use Ruby+Rails in the enterprise. Keeping it at 0.x means
that it has zero chance of getting installed in many places.

 

[Kirk Haines]

Also I think fcgi should get a version bump to 1.0 . Version numbers
like 0.8.6 are just confusingly smelling like beta software. There are
several companies (37signals, snowdevil...) futures being trusted to
this code so I really think it deserves the production ready tag

It's not ready for a version bump to 1.0. There were serious, blatant,
obvious memory leaks in 0.8.5. It took me about an hour to walk through
the code, generally understand it, and find them all (I hope), and I am not
a master C programmer. That suggests to me that there has not been a lot
of effort applied to making the C extension really robust, even though it
does now appear to work fine, even when abused pretty hard.

However, I can open up fcgi.c and find areas that could be made more robust
or more performant quite easily at this point. Overall, the code is pretty
good, and with the patches, it IS stable, but it's stable pre 1.0 code. It
needs some work, still, before being called 1.0.

I'm going to be using it far more extensively in the future, so I am happy,
as with the memory leak patch, to do some of this work, but I don't think
anyone should be too hasty about stamping 1.0 on it, lest we make it look
like a Microsoft versioned product (i.e. needs to get to version 3.0 before
it is any good).


Kirk Haines

 

[Aredridel]

In principal, I agree with you 100%. But this world is full of people
that make technology decisions based on PERCEPTION or outdated policies
rather than technical merit or common sense.

That's sad. I'm tempted to say "let them go the way of the dinosaur" if
their policies are so inane. This is why large companies get
outmaneuvered by small ones.

I know of one company that wouldn't allow Apache 1.3 to replace IIS 4.0
solely on the basis of IT policy not allowing software with version 1.x
to be installed.

Aye. And with that policy, they'd probably install Apache 2.0 when it's
in a state less stable than Apache 1.

So while I agree with you in principal, I think fcgi going 1.0, 1.1 or
2.1 (better still) would make it SUBSTANTIALLY easier to convince many
companies to use Ruby+Rails in the enterprise. Keeping it at 0.x means
that it has zero chance of getting installed in many places.

I'd say that it's not there yet, then. If that's the company policy,
then they'd be wise to re-state it: We don't use technologies with out
least being proven for four years... or whatever number makes sense.

Simply changing the version to 1.0 isn't going to help. Getting tons of
production-use feedback collected would be good as a marker for 1.0...
I'd only feel comfortable calling something 1.0 if it's either so
trivial as to be fairly obviously correct (my ruby-xattr library comes
to mind), or having been extensively tested by at least a few people,
and getting some good feedback. I think ruby-fcgi is more or less at a
0.8.6 out of 1.0 as far as testing, if you assume 1.0 is "it works, all
features stated work and it doesn't crash under any reasonable
circumstance (even failure states)"

I'd much rather have it be considered pre-1.0 and get it tested well
before someone with a truly mission-critical need puts the code in some
place where it will fail. I'd rather it not be used yet, than have it
break and put egg on someone's face.

Ari

 

[Tobias Luetke]

Be that as it may, the essence of my post was that we need a new gem.

There are hundreds of rails app in production and new ones coming out
daily while its growth is still exponential. The way people get fcgi
library right now is by gems. As long as the gem isn't updated all of
ruby has a memory leak to the average user.

Also 1.0 suggests mature and recommended for consumption, not stable.
As opposed to 0.8.5 which suggests toy code, please try it out. Fcgi
is indeed mature and production ready, even in its current memory
leaking state.

It also doesn't seem to have a real maintainer right now so calling it
1.0 now would be a good idea because it doesn't seem like it will get
there under its current stewardship incrementally.

 

[Aredridel]

Be that as it may, the essence of my post was that we need a new gem.

Agreed! It's gotta be up-to-date, especially for critical
infrastructure.

There are hundreds of rails app in production and new ones coming out
daily while its growth is still exponential. The way people get fcgi
library right now is by gems. As long as the gem isn't updated all of
ruby has a memory leak to the average user.
Yup.

Also 1.0 suggests mature and recommended for consumption, not stable.
As opposed to 0.8.5 which suggests toy code, please try it out. Fcgi
is indeed mature and production ready, even in its current memory
leaking state.

Aye! I put far more care into the label "production ready".

I say < 0.5 sounds toyish; until 1.0, in serious development ... but
then, it varies by project.

 

[Paul Hanchett]

You'll need a compatible compiler in your path.

And that would be? I have gcc 3.3.3 for cygwin and Microsoft cl (aka
vc) 12.0.8168. Is there something else I should have?

Paul

 

[Dick Davies]

And that would be? I have gcc 3.3.3 for cygwin and Microsoft cl (aka
vc) 12.0.8168. Is there something else I should have?

Header files.

 

[Aredridel]

Header files.

Header files, for both the FastCGI dev kit, and your OS' C api.