Project

General

Profile

Actions

Backport #1964

closed

Compile Issue on Solaris 10

Added by btoal (Brian Toal) about 15 years ago. Updated over 12 years ago.

Status:
Rejected
[ruby-core:24989]

Description

=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


Files

1964-proposed-fix.diff (822 Bytes) 1964-proposed-fix.diff cfs (Charles Stephens), 09/01/2010 07:21 AM
Actions #1

Updated by btoal (Brian Toal) about 15 years ago

=begin
I forgot to include the compile options and environment variables that I used.

./configure --prefix=/tcg/tcg_app/ruby/1.9.1-p243 --without-gcc

export PATH=/opt/SUNWspro/bin:$PATH

export CC=cc
export CXX=CC
export CFLAGS="-fast -xarch=v9 -xcode=pic32"
export CXXFLAGS="-fast -xarch=v9 -xcode=pic32"
export CPPFLAGS="-I$HOME/tools/include -I$HOME/openssl/rel/include"
export LDFLAGS="-L$HOME/tools/lib"

=end

Actions #2

Updated by naruse (Yui NARUSE) about 15 years ago

  • Status changed from Open to Rejected

=begin
Solaris is not supported.
=end

Actions #3

Updated by hasari (Hiro Asari) about 15 years ago

=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

Actions #4

Updated by djberg96 (Daniel Berger) about 15 years ago

=begin
Yui NARUSE wrote:

Issue #1964 has been updated by Yui NARUSE.

Status changed from Open to Rejected

Solaris is not supported.

http://redmine.ruby-lang.org/issues/show/1964

You're not supporting Solaris the OS? Or the Sun compiler? Or OpenSSL on
Solaris?

Regards,

Dan

=end

Actions #5

Updated by naruse (Yui NARUSE) about 15 years ago

=begin
2009/10/16 10:25, Daniel Berger wrote:

You're not supporting Solaris the OS? Or the Sun compiler? Or OpenSSL on
Solaris?

OS and its environment.

We don't have them, so we can't reproduce problems arround them.
This is why those are not supported.

If you have a patch and it clearly doesn't have side effects,
the patch may be imported.

--
NARUSE, Yui

=end

Actions #6

Updated by cfs (Charles Stephens) about 14 years ago

=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

Actions #7

Updated by naruse (Yui NARUSE) about 14 years ago

  • Priority changed from 5 to Normal

=begin
1.9 has rb_str_set_len in ruby.h, so the definition is not used.
=end

Actions #8

Updated by cfs (Charles Stephens) about 14 years ago

=begin
Someone tell ext/openssl then, it is still using its own private erroneous macro. ;)
=end

Updated by nahi (Hiroshi Nakamura) over 13 years ago

  • Tracker changed from Bug to Backport
  • Category set to ext
  • Assignee set to nahi (Hiroshi Nakamura)

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.

Updated by graza (Graham Agnew) over 12 years ago

hasari (Hiro Asari) wrote:

=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:

PKG_CONFIG_PATH=/usr/lib/sparcv9/pkgconfig.

Regards,
Graham.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0