[3.4b] ruby bindings fail to build
Reto Glauser
Member Reto GlauserOrganization: Junisphere SystemsProject: Business Service Management ✭
in Bug Reports
make -C rb make: Entering directory `/tmp/Ice-3.4b/rb' making all in src make[1]: Entering directory `/tmp/Ice-3.4b/rb/src' making all in IceRuby make[2]: Entering directory `/tmp/Ice-3.4b/rb/src/IceRuby' c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Connection.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Communicator.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Endpoint.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Init.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g ImplicitContext.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Logger.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g ObjectFactory.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Operation.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Properties.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Proxy.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Slice.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Types.cpp c++ -c -I. -I.. -I../../../cpp/include -I/usr/lib64/ruby/1.8/x86_64-linux -m64 -Wall -D_REENTRANT -fPIC -g Util.cpp Util.cpp: In function 'Ice::Long IceRuby::getLong(VALUE)': Util.cpp:161: error: invalid conversion from 'void*' to 'unsigned int*' make[2]: *** [Util.o] Error 1
A static_cast allows the build to finish:
--- ./Ice-3.4b/rb/src/IceRuby/Util.cpp.orig 2010-02-03 14:46:16.000000000 +0100
+++ ./Ice-3.4b/rb/src/IceRuby/Util.cpp 2010-02-03 14:24:34.000000000 +0100
@@ -158,7 +158,7 @@
{
throw RubyException(rb_eRangeError, "bignum too big to convert into long");
}
- BDIGIT *ds = RBIGNUM_DIGITS(v);
+ BDIGIT *ds = static_cast<unsigned int *>(RBIGNUM_DIGITS(v));
BDIGIT_DBL num = 0;
while(len--)
{
0
Comments
What flavor of Linux and which version of GCC are you using?
Regards,
Mark
I have tested Ice Ruby on Gentoo 64 and was not able to reproduce the problem, our setup are very similar, seems to me that differences in CXXFLAGS could be the cause of this, we will further investigate that and include a fix in 3.4 release.
Bests,
José
actually i was wrong about CXXFLAGS, as Ice source distribution doesn't use portage CXXFLAGS to build.
What ruby version were you using?
i have that:
Bests Regards,
José
nice catch. Unmasking, keywording and installing ruby-1.9 seems to do the trick:
even though ruby1.8 is still active:
Looks like Ice-3.4b depends on ruby1.9 ?
Ice For Ruby requires ruby >= 1.8.1
In my other gentoo setup (x86) it builds fine with 1.8.7
What Ruby 1.8 version do you have?
Bests Regards,
José
and both fail with 1.8.7_p249
# eix dev-lang/ruby [I] dev-lang/ruby Available versions: (1.8) 1.8.6_p388 1.8.7_p249 (1.9) {M}(~)1.9.1_p243 {berkdb debug doc emacs examples gdbm ipv6 rubytests socks5 ssl threads tk xemacs} Installed versions: 1.8.7_p249(1.8)(08:02:33 PM 01/20/2010)(berkdb gdbm ssl -debug -doc -emacs -examples -ipv6 -rubytests -socks5 -threads -tk -xemacs) 1.9.1_p243(1.9)(08:13:08 AM 02/05/2010)(berkdb gdbm ssl -debug -doc -emacs -examples -ipv6 -rubytests -socks5 -tk -xemacs) Homepage: http://www.ruby-lang.org/ Description: An object-oriented scripting languagee.g.
dev-lang/ruby-1.8.7_p249 and gcc-4.3.4
Previous 1.8.7 versions seems not affected, ruby 1.8.7 (2009-06-12 patchlevel
174) just works fine.
We will include a fix in 3.4.0 final release.
Thanks for point this out, and help to track it down.
Bests Regards,
José