ACCEPT_KEYWORDS="~amd64" emerge -v ruby-gnome2 Calculating dependencies ...done! >>> emerge (1 of 8) dev-ruby/ruby-libart2-0.11.0 to / >>> md5 src_uri ;-) ruby-gnome2-all-0.11.0.tar.gz >>> Unpacking source... >>> Unpacking ruby-gnome2-all-0.11.0.tar.gz to /var/tmp/portage/ruby-libart2-0.11.0/work >>> Source unpacked. can't find header files for ruby. !!! ERROR: dev-ruby/ruby-libart2-0.11.0 failed. !!! Function ruby-gnome2_src_compile, Line 33, Exitcode 1 !!! extconf.rb failed !!! If you need support, post the topmost build error, NOT this status message. Reproducible: Always Steps to Reproduce: 1. emerge ruby-libart2-0.11.0 2. 3. Actual Results: Calculating dependencies ...done! >>> emerge (1 of 8) dev-ruby/ruby-libart2-0.11.0 to / >>> md5 src_uri ;-) ruby-gnome2-all-0.11.0.tar.gz >>> Unpacking source... >>> Unpacking ruby-gnome2-all-0.11.0.tar.gz to /var/tmp/portage/ruby-libart2-0.11.0/work >>> Source unpacked. can't find header files for ruby. !!! ERROR: dev-ruby/ruby-libart2-0.11.0 failed. !!! Function ruby-gnome2_src_compile, Line 33, Exitcode 1 !!! extconf.rb failed !!! If you need support, post the topmost build error, NOT this status message. Expected Results: installed Portage 2.0.51-r3 (default-linux/amd64/2004.3, gcc-3.4.2, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r9 x86_64) ================================================================= System uname: 2.6.9-gentoo-r9 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.6-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X acpi alsa apm artworkextra berkdb bitmap-fonts cdr crypt cups divx4linux dvd dvdr dvdread eds esd f77 fam flac fortran gdbm gif gnome gnomedb gpm gstreamer gtk gtk2 howl imlib ipv6 java jp2 jpeg junit libwww lzw lzw-tiff mad motif mozilla mp3 mpeg mplayer multilib ncurses network nls nvidia offensive oggvorbis opengl oss pam perl png python readline rtc ruby samba sdl spell sqlite ssl tcpd tetex theora tiff truetype unicode usb userlocales xinerama xml xml2 xmms xpm xrandr xv xvid xvmc zlib"
This bug is lib64-related, and occurs in other dev-ruby packages too. The cause is likely some hardcoded paths inside the build scripts. I don't know enough about the build system myself, but hopefully someone in the ruby herd does...
*** Bug 89132 has been marked as a duplicate of this bug. ***
Okay, I've got a feeling that this is due to hardcoded /lib paths in the ruby ebuilds. The ebuilds already have inherit eutils, so all that's needed is to replace every instance of /lib with $(get_libdir). I've refrained from doing this because I don't want to tread on anyone's feet. If it's okay though, I'll happily make the changes. Thanks, Tom
will have a look into it asap
Created attachment 56435 [details, diff] ruby-1.8.2-r1.ebuild.patch Okay, I've verified my fix to the ruby ebuild, I'll commit it unless someone from ruby@ objects.
thanks slarti
slarti, please go ahead with your changes, I'm low on time at the moment and I don't think anyone else will object.
Committed. Thanks ruby people :)
Okay, this doesn't fix it. I was in such a muddle that I installed libart_lgpl thinking it was the ruby module and the fix was verified. This doesn't fix it, but... on the upside, at least we got rid of some hardcoded paths in the ruby ebuild :) I don't know much about mkmf.rb or rbconfig. I'm really stuck on this one. The changes will need to be made in the eclass somewhere though.
Created attachment 56607 [details, diff] ruby multilib fixes Here's a patch that does actually fixes the problem. I've tested this with some of the example programs on the ruby-gnome2 site and am currently playing sokoban ;-) I'm happy to commit this unless anyone objects?
Comment on attachment 56607 [details, diff] ruby multilib fixes --- ruby-1.8.2-r1.ebuild 18 Apr 2005 16:57:37 -0000 1.5 +++ ruby-1.8.2-r1.ebuild 18 Apr 2005 23:13:48 -0000 @@ -51,6 +51,10 @@ epatch ${FILESDIR}/ruby-rdoc-gentoo.diff epatch ${FILESDIR}/ruby-1.8.2-soap.diff epatch ${FILESDIR}/ruby-1.8.2-unittest.diff + + # Fix multilib error in configure script + sed -i -e 's:\(RUBY_LIB_PREFIX="\)${prefix}/lib:\1${libdir}:' \ + configure.in || die "sed failed" } src_compile() { @@ -76,6 +80,7 @@ fi econf --program-suffix=${SLOT/./} --enable-shared \ + --with-sitedir=/usr/$(get_libdir)/ruby/site_ruby \ $(use_enable socks5 socks) \ $(use_enable doc install-doc) \ $(use_enable threads pthread) \
OK, firstly sorry about the mess with the patches above.. it was late. Had a chat with blubb about this and we agreed that /usr/lib/ruby/site-ruby is the correct location for the site-packages. It's mostly arch-independant scripts that get installed here and the few shared objects get put in a $ARCH-linux/ subdirectory. The sed line on the other hand is a neccessary multilib fix IMO (just corrects a hard coded path in the configure script) so I'm commiting that and closing this bug. Hope that's ok.
I think this is basically the same problem with bug #76359, but I don't have any machine to test the patch :( It seems that matsuu's patch in bug #76359 is the correct fix IMO. (I was waiting for trying the patch because ruby-1.8.3pre was announced to have been released on 12 Apr, but that hasn't happened yet)
Yes, looks like the same problem. Matsuu's sed line replaces the hardcoded path with the correct hardcoded path. Mine replaces it with ${libdir}, thus inheriting the path from the --libdir= configure option (that gets added by econf). I personally think that's the cleaner way to do it but either one works. Feel free to replace the sed lines if you so desire (either way, bug #76359 can be closed).