Bug #5384

Ruby 1.9.3-RC1 Fails to Compile on Illumos (OpenSolaris)

Added by Cyrus Lopez over 2 years ago. Updated over 1 year ago.

[ruby-core:39796]
Status:Third Party's Issue
Priority:Normal
Assignee:-
Category:-
Target version:-
ruby -v:- Backport:

Description

An attempt was made recently to compile http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-rc1.tar.bz2 and it seems every call to the compiler passes DFILEOFFSETBITS=64 which returns the fatal error 'large files are not supported by libelf' on a fresh install of OpenIndiana with GCC 4.6.1.

Snippet of Error:
....
compiling addr2line.c
In file included from /usr/include/link.h:31:0,
from addr2line.c:42:
/usr/include/libelf.h:42:2: error: #error "large files are not supported by libelf"
make: *** [addr2line.o] Error 1
....

Discussion on IRC pointed out http://src.illumos.org/source/xref/illumos-gate/usr/src/head/libelf.h#41 and a request was made to file a bug report.


Related issues

Related to ruby-trunk - Bug #8268: ruby 2.0.0 incorrectly detects debugflags on SmartOS / gc... Closed 04/15/2013

History

#1 Updated by Naohisa Goto over 2 years ago

Solaris 10 released from Oracle (Sun Microsystems) does not have such limitation.
It seems the problem is Illumos (OpenSolaris) specific problem,
and the title "on Solaris" is wrong.

#2 Updated by Naohisa Goto over 2 years ago

  • Subject changed from Ruby 1.9.3-RC1 Fails to Compile on Solaris to Ruby 1.9.3-RC1 Fails to Compile on Illumos (OpenSolaris)

#3 Updated by Motohiro KOSAKI over 2 years ago

  • ruby -v changed from 1.9.3rc1 to -

An attempt was made recently to compile http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-rc1.tar.bz2 and it seems every call to the compiler passes DFILEOFFSETBITSd which returns the fatal error 'large files are not supported by libelf' on a fresh install of OpenIndiana with GCC 4.6.1.

Snippet of Error:
....
compiling addr2line.c
In file included from /usr/include/link.h:31:0,
                from addr2line.c:42:
/usr/include/libelf.h:42:2: error: #error "large files are not supported by libelf"
make: *** [addr2line.o] Error 1
....

I wonder how OpenSolaris support large files if it doesn't support
DFILEOFFSETBITSd.
Is it broken? or is there unknown alternative way?

I have no idea how to make fixed patch.

#4 Updated by Matt Lewandowsky over 2 years ago

=begin
In all fairness, Ruby 1.9.3-RC1 doesn't compile out of the box on Sun Solaris 10, either, but for a different reason (one which should be handled by configure, but is not):

compiling iconv.c
linking shared-object iconv.so
ld: fatal: library -liconv: not found
ld: fatal: File processing errors. No output written to ../../.ext/sparc-solaris2.10/iconv.so
collect2: ld returned 1 exit status
gmake[2]: *** [../../.ext/sparc-solaris2.10/iconv.so] Error 1
gmake[2]: Leaving directory /home/lewellyn/ruby-1.9.3-rc1/ext/iconv'
gmake[1]: *** [ext/iconv/all] Error 2
gmake[1]: Leaving directory
/home/lewellyn/ruby-1.9.3-rc1'
gmake: *** [build-ext] Error 2
670 lewellyn@looking-glass$ uname -a
SunOS looking-glass 5.10 Generic_137137-09 sun4u sparc SUNW,UltraAX-i2 Solaris

As for illumos's libelf, it's currently unchanged from what Sun open-sourced in 2005. The comments in the file indicate that it's probably mostly unchanged from what AT&T had 20 years ago. [http://src.illumos.org/source/xref/illumos-gate/usr/src/head/libelf.h?a=true&h=#40] I'd personally be surprised that Ruby 1.9.3-RC1 builds on a stock Solaris without a replacement libelf.

And, as for (({FILEOFFSET_BITS=64})), just use it wherever you need 64-bit file support. I expect addr2line.c doesn't need it, correct?

Have you also tested on the Oracle Solaris 11 Express or Early Access?
=end

#5 Updated by Naohisa Goto over 2 years ago

In all fairness, Ruby 1.9.3-RC1 doesn't compile out of the box on Sun Solaris 10, either, but for a different reason (one which should be handled by configure, but is not):

compiling iconv.c
linking shared-object iconv.so
ld: fatal: library -liconv: not found

On the machine, I suppose GNU libiconv is installed and iconv.h coming from GNU libiconv is recognized by the compiler but the library directory of GNU libiconv is not included in the default library search path.
Giving LDFLAGS="-L/usr/local/lib -R/usr/local/lib" to configure may solve the error.

#6 Updated by Cyrus Lopez over 2 years ago

Naohisa Goto wrote:

In all fairness, Ruby 1.9.3-RC1 doesn't compile out of the box on Sun Solaris 10, either, but for a different reason (one which should be handled by configure, but is not):

compiling iconv.c
linking shared-object iconv.so
ld: fatal: library -liconv: not found

On the machine, I suppose GNU libiconv is installed and iconv.h coming from GNU libiconv is recognized by the compiler but the library directory of GNU libiconv is not included in the default library search path.
Giving LDFLAGS="-L/usr/local/lib -R/usr/local/lib" to configure may solve the error.

I have tried this and I am met with the same error still.

#7 Updated by Naohisa Goto over 2 years ago

I have tried this and I am met with the same error still.

I cannot reproduce the error on my machines running Solaris 10, with GNU libiconv or with the native iconv on Solaris 10. So, I think this would be specific to your machine.

If you are using native iconv on Solaris, SUNWuiu8 package is required, and SUNWciu8, SUNWhiu8, SUNWjiu8, and SUNWkiu8 packages are recommended.
(Reference: http://developer.gnome.org/glib/2.30/glib-building.html )

Since the iconv issue is different from the main topic, please report the issue as a new Bug, with following information and files.

  • compiler name and version
  • which iconv is installed and used
  • configure options
  • ./config.log
  • ./ext/iconv/mkmf.log

#8 Updated by Naohisa Goto over 2 years ago

Naohisa Goto wrote:

Solaris 10 released from Oracle (Sun Microsystems) does not have such limitation.

I'm sorry I mistook. /usr/include/libelf.h in Oracle Solaris 10 still does not support large files when _ILP32 is defined.

The reason why Solaris10 is not affected is that it does not have dliteratephdr() and the macro HAVEDLITERATE_PHDR is not defined and thus addr2line.c does not include that internally includes libelf.h.

Simple workaround is to remove the line "#define HAVEDLITERATE_PHDR 1" in .ext/include/*/ruby/config.h after configure.

Another possible workaroud is to install alternative libelf from http://www.mr511.de/software/english.html and set CPPFLAGS="-I/usr/local/include/libelf -I/usr/local/include" (when libelf is installed to /usr/local) when configure.

#9 Updated by Naohisa Goto over 2 years ago

It seems the problem about the use of dliteratephdr issue() defined in was already reported, but the bug report seems to be disappeared possibly due to the change of project website.

In http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02770.html

#10 Updated by Naohisa Goto about 2 years ago

  • Status changed from Open to Third Party's Issue

I think this is a bug of Illumos (OpenSolaris).

In Solaris 11, it was treated as a bug of Solaris 11 and was already fixed.
http://wesunsolve.net/bugid/id/6997934

See the discussion in Illumos community for the progress.
https://www.illumos.org/issues/1587

For a workaround,
./configure accvfuncdliterate_phdr=no
should work.

Also available in: Atom PDF