=begin
I'm trying to compile ruby-1.9.1-p243 on Solaris 10.
$ uname -a
SunOS condor 5.10 Generic_141414-01 sun4u sparc SUNW,Sun-Fire-V240
Running make I get the following error:
$ make
cc -I. -I../../.ext/include/sparc-solaris2.10 -I../.././include -I../.././ext/openssl -DRUBY_EXTCONF_H="extconf.h" -I/tcg/tcg_app/tools/include -I/tcg/tcg_app/openssl/rel/include -KPIC -fast -xarch=v9 -xcode=pic32 -g -I/usr/sfw/include -o ossl_asn1.o -c ossl_asn1.c
"ossl_asn1.c", line 704: improper member use: ptr
"ossl_asn1.c", line 704: improper member use: len
"ossl_asn1.c", line 987: improper member use: ptr
"ossl_asn1.c", line 987: improper member use: len
cc: acomp failed for ossl_asn1.c
make: *** [ossl_asn1.o] Error 2
What does "improper member use" mean and how do I resolve this?
=end
=begin
'-xarch=v9' (or its modern replacement '-m64') appears to be problematic. Without CFLAGS as specified above, Sun's C compiler can create the ruby binary just fine.
If I had more time to investigate, I might, but for now, that's the answer to this problem.
=end
=begin
This is a bug ext/openssl/ruby_missing.h where the rb_str_set_len macro didn't take into account changes in 'struct RString' from 1.8 to 1.9. Attached is a proposed fix with corrects the problem.
=end
That rb_str_set_len definition is for 1.8. The root cause is that ruby 1.9.1 does not have rb_str_set_len and it does not compatible with 1.8.
Since we've already dropped support for 1.9.1, I think it's OK to mark it as 'Rejected' now. Charles, your patch looks correct for ruby_1_9_1 branch. I'm sorry for late response and this result.
=begin
'-xarch=v9' (or its modern replacement '-m64') appears to be problematic. Without CFLAGS as specified above, Sun's C compiler can create the ruby binary just fine.
If I had more time to investigate, I might, but for now, that's the answer to this problem.
=end
Hi Asari-san,
I was having this problem and took the time to investigate today.
The problem is to do with the extconf.rb file's call to pkg_config('openssl') - the returned linker flags are pointing to the 32-bit libraries by default. So when it tests for have_func('rb_str_set_len') it fails to compile the test program because the linker path is wrong; it can't link the 32-bit libraries when -m64 is in the CFLAGS.
I've been able to compile and test 64-bit Ruby using native compilers by exporting the following environment variable value: