========================================
$ LANG=en_US.utf8 sudo gem install RedCloth
Fetching: RedCloth-4.2.7.gem (100%)
Building native extensions. This could take a while...
ERROR: Error installing RedCloth:
ERROR: Failed to build gem native extension.
/opt/rubies/ruby-1.9.2-p180/bin/ruby extconf.rb
checking for main() in -lc... yes
creating Makefile
make
gcc -I. -I/opt/rubies/ruby-1.9.2-p180/include/ruby-1.9.1/x86_64-linux
- -I/opt/rubies/ruby-1.9.2-p180/include/ruby-1.9.1/ruby/backward
- -I/opt/rubies/ruby-1.9.2-p180/include/ruby-1.9.1 -I. -fPIC -O3 -ggdb
- -Wextra -Wno-unused-parameter -Wno-parentheses -Wpointer-arith
- -Wwrite-strings -Wno-missing-field-initializers -Wno-long-long -fPIC
- -O0 -Wall -Werror -o redcloth_inline.o -c redcloth_inline.c
ragel/redcloth_inline.c.rl: In function ‘red_block’:
ragel/redcloth_inline.c.rl:99:9: error: variable ‘attr_regs’ set but not
used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make: *** [redcloth_inline.o] Error 1
Gem files will remain installed in
/opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1/gems/RedCloth-4.2.7 for
inspection.
Results logged to
/opt/rubies/ruby-1.9.2-p180/lib/ruby/gems/1.9.1/gems/RedCloth-4.2.7/ext/redcloth_scan/gem_make.out
Obviously RedCloth generates some warnings during compilation, and now
RubyGems advises the compiler to treat them as errors--as far as I know
this wasn't the case with previous versions of RubyGems, because some
days ago RedCloth installed without problems (no, no new release of
RedCloth happened in the meantime). This causes the installation of
RedCloth to fail.
I'm not against treating warnings as errors, but there should be a way
to disable this setting, maybe via a commandline option
- --ignore-compilation-warnings or something like that, because I'm not a
RedCloth developer and therefore not interested in the warnings.
Further information on my system:
uname -a:
Linux hades 2.6.38-ARCH #1 SMP PREEMPT Tue May 3 07:40:34 CEST 2011
x86_64 AMD Athlon(tm) II X4 640 Processor AuthenticAMD GNU/Linux
Can we stop with the knee-jerk reaction to blame rubygems for everything including the national deficit?
Rubygems calls make/rake/whatever. That's it.
···
On May 12, 2011, at 03:35 , Quintus wrote:
Obviously RedCloth generates some warnings during compilation, and now
RubyGems advises the compiler to treat them as errors--as far as I know
this wasn't the case with previous versions of RubyGems, because some
days ago RedCloth installed without problems (no, no new release of
RedCloth happened in the meantime). This causes the installation of
RedCloth to fail.
You're right, that's odd. Then it's a bug in RedCloth, as it's obviously
supposed to build without warnings. I'll report this to the RedCloth
team. Thanks.
somedays ago RedCloth installed without problems
It seems your environment has changed in some other way. Perhaps GCC
has been upgraded?
Indeed, last friday I upgraded several things. I'm not sure wheather or
not GCC has been affected, but at least it's possible. Thanks again.
Vale,
Marvin
···
Am 12.05.2011 13:27, schrieb Nikolai Weibull:
On Thu, May 12, 2011 at 12:35, Quintus <sutniuq@gmx.net> wrote:
Was this really necessary? Make the output clearer instead of
complaining that people don’t understand it.
···
On Thu, May 12, 2011 at 23:00, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On May 12, 2011, at 03:35 , Quintus wrote:
Obviously RedCloth generates some warnings during compilation, and now
RubyGems advises the compiler to treat them as errors--as far as I know
this wasn't the case with previous versions of RubyGems, because some
days ago RedCloth installed without problems (no, no new release of
RedCloth happened in the meantime). This causes the installation of
RedCloth to fail.
Can we stop with the knee-jerk reaction to blame rubygems for everything including the national deficit?
I can't make the output clearer as I didn't make the output to begin with. Again, rubygems just calls make/rake/whatever. That's it.
···
On May 12, 2011, at 14:21 , Nikolai Weibull wrote:
On Thu, May 12, 2011 at 23:00, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On May 12, 2011, at 03:35 , Quintus wrote:
Obviously RedCloth generates some warnings during compilation, and now
RubyGems advises the compiler to treat them as errors--as far as I know
this wasn't the case with previous versions of RubyGems, because some
days ago RedCloth installed without problems (no, no new release of
RedCloth happened in the meantime). This causes the installation of
RedCloth to fail.
Can we stop with the knee-jerk reaction to blame rubygems for everything including the national deficit?
Rubygems calls make/rake/whatever. That's it.
Was this really necessary? Make the output clearer instead of
complaining that people don’t understand it.
The problem is not RubyGems actually, but that RedCloth turns -Werror
so warnings are treated as errors and 'make' interpret GCC exit code
as error, not success.
If you see the output of the gcc part:
ragel/redcloth_inline.c.rl:99:9: error: variable ‘attr_regs’ set but
not
used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make: *** [redcloth_inline.o] Error 1
That is not RubyGems, that is gcc output of make running. Has nothing
to do with make the output cleaner.
RubyGems takes the error of Make and tells you "there was an error
with compilation of extension". RubyGems can't guess or determine what
failed to provide a better error for you, that will be overly
complicated.
As OP said, there must be a change in GCC version or even Ruby version
that could have been the root of this issue.
···
On May 12, 6:21 pm, Nikolai Weibull <n...@bitwi.se> wrote:
> Rubygems calls make/rake/whatever. That's it.
Was this really necessary? Make the output clearer instead of
complaining that people don’t understand it.
Obviously RedCloth generates some warnings during compilation, and now
RubyGems advises the compiler to treat them as errors--as far as I know
this wasn't the case with previous versions of RubyGems, because some
days ago RedCloth installed without problems (no, no new release of
RedCloth happened in the meantime). This causes the installation of
RedCloth to fail.
Can we stop with the knee-jerk reaction to blame rubygems for everything including the national deficit?
Rubygems calls make/rake/whatever. That's it.
Was this really necessary? Make the output clearer instead of
complaining that people don’t understand it.
I can't make the output clearer as I didn't make the output to begin with.
As a project administrator for RubyGems, I believe that you can, see
below for clarification.
Again, rubygems just calls make/rake/whatever. That's it.
Yes, I know that, hence the answer I provided earlier in this thread.
But there seems to be some confusion over who’s responsible when these
things happen. From time to time, people post complaints to the
ruby-installer mailing list that it is the cause of gem build
failures, so there’s plenty of blame going around.
If RubyGems was to output
Failed to build gem native extension. This is a problem with the X
gem, not RubyGems. Please visit
#{Gem::Specification#homepage} or email the author at
#{Gem::Specification#email} to report it. The build output was
/opt/rubies/ruby-1.9.2-p180/bin/ruby extconf.rb
checking for main() in -lc... yes
creating Makefile
…
or something less thrown-together-for-demonstration, then perhaps
users would find it easier to identify the source of the error and how
to resolve it.
···
On Fri, May 13, 2011 at 01:59, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On May 12, 2011, at 14:21 , Nikolai Weibull wrote:
On Thu, May 12, 2011 at 23:00, Ryan Davis <ryand-ruby@zenspider.com> wrote:
Was this really necessary? Make the output clearer instead of
complaining that people don’t understand it.
The problem is not RubyGems actually, but that RedCloth turns -Werror
so warnings are treated as errors and 'make' interpret GCC exit code
as error, not success.
As I tried to explain to Ryan in a subsequent email, what I meant was
that I didn’t think it necessary to complain about Quintus’s question
in such a harsh way, especially /after/ I had already provided an
answer.
I agree that RubyGems gets some unwarranted flak, but my point was
that users obviously have a hard time discerning what’s at fault when
an error occurs when installing a gem. By improving the output of
RubyGems when an error occurs, using information provided with the
gem, such as home page, author, and email address, users will know who
to contact to report said error.
RubyGems takes the error of Make and tells you "there was an error
with compilation of extension". RubyGems can't guess or determine what
failed to provide a better error for you, that will be overly
complicated.
As OP said, there must be a change in GCC version or even Ruby version
that could have been the root of this issue.
No, I said that.
I don’t understand why I am constantly being misunderstood, but it
seems that I am at fault. Perhaps I should make my output clearer.
···
On Fri, May 13, 2011 at 15:50, Luis Lavena <luislavena@gmail.com> wrote:
On May 12, 6:21 pm, Nikolai Weibull <n...@bitwi.se> wrote:
I agree that RubyGems gets some unwarranted flak, but my point was
that users obviously have a hard time discerning what’s at fault when
an error occurs when installing a gem. By improving the output of
RubyGems when an error occurs, using information provided with the
gem, such as home page, author, and email address, users will know who
to contact to report said error.
Even better if a fork/pull request is done at GitHub:
I think is not that hard to implement and for sure can serve better to
the user.
> RubyGems takes the error of Make and tells you "there was an error
> with compilation of extension". RubyGems can't guess or determine what
> failed to provide a better error for you, that will be overly
> complicated.
> As OP said, there must be a change in GCC version or even Ruby version
> that could have been the root of this issue.
No, I said that.
I don’t understand why I am constantly being misunderstood, but it
seems that I am at fault. Perhaps I should make my output clearer.
Well, some of your answers do not show up in my ruby-talk copy of this
thread, so seems is not your fault been misunderstood.
···
On May 13, 11:25 am, Nikolai Weibull <n...@bitwi.se> wrote: