[ ruby-gnome2-Bugs-3383158 ] 1.0.0 fails to build with LANG=C and ruby1.9.1

[SourceForge.net <no...@so...>]

Bugs item #3383158, was opened at 2011-07-31 01:03
Message generated for change (Tracker Item Submitted) made by terceiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=470969&aid=3383158&group_id=53614

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Antonio Terceiro (terceiro)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.0.0 fails to build with LANG=C and ruby1.9.1

Initial Comment:
Hello, 

I am working to have ruby-gnome2 1.0.0 in Debian, and the gtk2 module fails to build for ruby 1.9 when using the 'C' locale in an update to date Debian unstable system. See the copy-pasted terminal output below:

terceiro@morere:/tmp/tmp$ ll
total 1140
-rw-r--r-- 1 terceiro terceiro 1160036 Jul 30 20:56 ruby-gnome2-all-1.0.0.tar.gz
terceiro@morere:/tmp/tmp$ tar xzf ruby-gnome2-all-1.0.0.tar.gz 
terceiro@morere:/tmp/tmp$ cd ruby-gnome2-all-1.0.0/gtk2/ext/gtk2/
terceiro@morere:/tmp/tmp/ruby-gnome2-all-1.0.0/gtk2/ext/gtk2$ ruby1.9.1 extconf.rb 
checking for GCC... yes
checking for rb_define_alloc_func() in ruby.h... yes
checking for rb_block_proc() in ruby.h... yes
checking for new allocation framework... yes
checking for attribute assignment... no
checking for cairo... yes
checking for rb_cairo.h... yes
checking for Win32 OS... no
checking for gthread-2.0... yes
checking for gtk+-2.0... yes
checking for st.h... yes
checking for ruby/st.h... yes
checking for target... x11
checking for gtk_plug_get_type() in gtk/gtk.h... yes
checking for gtk_socket_get_type() in gtk/gtk.h... yes
checking for pango_render_part_get_type() in gtk/gtk.h... yes
checking for gtk/gtkfilesystem.h... yes
checking for X11/Xlib.h... yes
checking for main() in -lX11... yes
checking for XReadBitmapFileData() in X11/Xlib.h... yes
checking for XGetErrorText() in X11/Xlib.h... yes
checking for gtk+-unix-print-2.0... yes
checking for rb_errinfo()... yes
creating ruby-gtk2.pc
creating Makefile
terceiro@morere:/tmp/tmp/ruby-gnome2-all-1.0.0/gtk2/ext/gtk2$ LANG=C ruby1.9.1 extconf.rb 
checking for GCC... yes
checking for rb_define_alloc_func() in ruby.h... yes
checking for rb_block_proc() in ruby.h... yes
checking for new allocation framework... yes
checking for attribute assignment... no
checking for cairo... yes
checking for rb_cairo.h... yes
checking for Win32 OS... no
checking for gthread-2.0... yes
checking for gtk+-2.0... yes
checking for st.h... yes
checking for ruby/st.h... yes
checking for target... x11
checking for gtk_plug_get_type() in gtk/gtk.h... yes
checking for gtk_socket_get_type() in gtk/gtk.h... yes
checking for pango_render_part_get_type() in gtk/gtk.h... yes
checking for gtk/gtkfilesystem.h... yes
checking for X11/Xlib.h... yes
checking for main() in -lX11... yes
checking for XReadBitmapFileData() in X11/Xlib.h... yes
checking for XGetErrorText() in X11/Xlib.h... yes
checking for gtk+-unix-print-2.0... yes
checking for rb_errinfo()... yes
creating ruby-gtk2.pc
extconf.rb:121:in `block (2 levels) in run': invalid byte sequence in US-ASCII (ArgumentError)
	from /usr/lib/ruby/1.9.1/pathname.rb:771:in `foreach'
	from /usr/lib/ruby/1.9.1/pathname.rb:771:in `each_line'
	from extconf.rb:120:in `block in run'
	from extconf.rb:119:in `each'
	from extconf.rb:119:in `run'
	from extconf.rb:188:in `block in <main>'
	from /usr/lib/ruby/1.9.1/pathname.rb:829:in `open'
	from /usr/lib/ruby/1.9.1/pathname.rb:829:in `open'
	from extconf.rb:182:in `<main>'
terceiro@morere:/tmp/tmp/ruby-gnome2-all-1.0.0/gtk2/ext/gtk2$ file -i * | grep -v ascii
rbgtkcellrendererspinner.c:   text/x-c; charset=utf-8
rbgtkinits.c:                 application/x-empty; charset=binary
rbgtkspinner.c:               text/x-c; charset=utf-8

This is triggered by UTF-8 data in rbgtkcellrendererspinner.c and rbgtkinits.c. I was able to build with the attached patch, but this does not look like the right way to fix the problem. I could not investigate further, but simply reading those files should not crash like that, and should also not depend on the current locale ...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=470969&aid=3383158&group_id=53614