trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: June 2012

Re: [trinity-devel] (Somewhat solved) tdebindings FTBFS on Slackware Current 32-bit

From: Darrell Anderson <humanreadable@...>
Date: Tue, 26 Jun 2012 18:56:06 -0700 (PDT)
I sent this message earlier today, but looks like the message disappeared while the server was disconnected from the world.





> That is one of the strangest include file directory trees I
> have seen!
>
> I (and the TDE compilation process) would expect to see:
> /usr/include/i486-linux/ruby-1.9.1/
> or
> /usr/include/ruby-1.9.1/
> or
> /usr/include/
>
> but not /usr/include/ruby-1.9.1/i486-linux/.  You may
> need to pass /usr/include/ruby-1.9.1/i486-linux/ as an extra include
> directory to the build process.


I added the following in my build script:

if [ "`uname -m`" = "x86_64" ]; then
  RUBY_EXTRA_INCLUDE="/usr/include/ruby-1.9.1/x86_64-linux/"
else
  RUBY_EXTRA_INCLUDE="/usr/include/ruby-1.9.1/i486-linux/"
fi
if [ -d "$RUBY_EXTRA_INCLUDE" ]; then
  echo "RUBY_EXTRA_INCLUDE: $RUBY_EXTRA_INCLUDE"
else
  echo "$RUBY_EXTRA_INCLUDE does not exist."
  exit 1
fi

CFLAGS=$CPUOPT \
CXXFLAGS=$CPUOPT \
./configure \
  ...
  --with-extra-includes=${RUBY_EXTRA_INCLUDE} \
  ...

tdebindings then built as usual. Yay! :-)

Possibly I stumbled across what is happening.

With ruby-1.9.1, I see the following in my configure output:

checking for ruby... ruby
checking for ruby dirs...
                  archdir /usr/lib/ruby/1.9.1/i486-linux,
                  sitearchdir /usr/lib/ruby/site_ruby/1.9.1/i486-linux,
                  sitedir /usr/lib/ruby/site_ruby/1.9.1,
                  libdir /usr/lib,
                  includedir /usr/include/ruby-1.9.1,
                  librubyarg -Wl,-R -Wl,/usr/lib -L/usr/lib -lruby
checking for ruby... (cached) ruby
checking for ruby dirs...
                  archdir /usr/lib/ruby/1.9.1/i486-linux,
                  sitearchdir /usr/lib/ruby/site_ruby/1.9.1/i486-linux,
                  sitedir /usr/lib/ruby/site_ruby/1.9.1,
                  libdir /usr/lib,
                  includedir /usr/include/ruby-1.9.1,
                  librubyarg -Wl,-R -Wl,/usr/lib -L/usr/lib -lruby
================================================================

With ruby-1.9.3 I see the following in my configure output:

checking for ruby... ruby
checking for ruby dirs... -e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.

                  archdir /usr/lib/ruby/1.9.1/i486-linux,
                  sitearchdir /usr/lib/ruby/site_ruby/1.9.1/i486-linux,
                  sitedir /usr/lib/ruby/site_ruby/1.9.1,
                  libdir /usr/lib,
                  includedir /usr/include/ruby-1.9.1,
                  librubyarg -Wl,-R -Wl,/usr/lib -L/usr/lib -lruby
checking for ruby... (cached) ruby
checking for ruby dirs... -e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.
-e:1: Use RbConfig instead of obsolete and deprecated Config.

                  archdir /usr/lib/ruby/1.9.1/i486-linux,
                  sitearchdir /usr/lib/ruby/site_ruby/1.9.1/i486-linux,
                  sitedir /usr/lib/ruby/site_ruby/1.9.1,
                  libdir /usr/lib,
                  includedir /usr/include/ruby-1.9.1,
                  librubyarg -Wl,-R -Wl,/usr/lib -L/usr/lib -lruby
================================================================

I think that prior to 1.9.3 somehow the configure process knew how to add the oddball ruby header location $archdir. With 1.9.3 our tdebindings configure process no longers does that properly.

Additionally, ruby-1.9.3 now comes packaged with a ruby.pc pkgconfig file. That newly added file hints at the build failure (this is the 32-bit version):

arch=i486-linux
sitearch=${arch}
prefix=/usr
exec_prefix=${prefix}
bindir=${exec_prefix}/bin
libdir=/usr/lib
includedir=${prefix}/include
MAJOR=1
MINOR=9
TEENY=1
ruby_version=1.9.1
RUBY_PROGRAM_VERSION=1.9.3
RUBY_BASE_NAME=ruby
RUBY_SO_NAME=${RUBY_BASE_NAME}
RUBY_INSTALL_NAME=${RUBY_BASE_NAME}
DEFFILE=
LIBPATH=
LIBRUBY_A=lib${RUBY_SO_NAME}-static.a
LIBRUBY_SO=lib${RUBY_SO_NAME}.so.${MAJOR}.${MINOR}.${TEENY}
LIBRUBY=${LIBRUBY_SO}
LIBRUBYARG_SHARED=-Wl,-R -Wl,${libdir} -L${libdir} -l${RUBY_SO_NAME}
LIBRUBYARG_STATIC=-Wl,-R -Wl,${libdir} -L${libdir} -l${RUBY_SO_NAME}-static
LIBRUBYARG=${LIBRUBYARG_SHARED}
LIBS=-lpthread -lrt -ldl -lcrypt -lm
DLDFLAGS=
ruby=${bindir}/${RUBY_INSTALL_NAME}
rubyhdrdir=${includedir}/${RUBY_BASE_NAME}-${ruby_version}
vendorhdrdir=${rubyhdrdir}/vendor_ruby
sitehdrdir=${rubyhdrdir}/site_ruby

Name: Ruby
Description: Object Oriented Script Language
Version: ${ruby_version}
URL: http://www.ruby-lang.org
Cflags: -I${rubyhdrdir}/${arch} -I${rubyhdrdir}
Libs: ${DLDFLAGS} ${LIBRUBYARG_SHARED} ${LIBS}
Requires:
================================================================

Notice the Cflags variable, which expands to /usr/include/ruby-1.9.1/i486-linux, which is where ruby/config.h is cleverly hidden, er, installed. (For 64-bit arch=x86_64-linux and libdir=/usr/lib64.)

Short-term solution?

Use --with-extra-include=/usr/include/ruby-1.9.1/i486-linux (or x86_64-linux for 64-bit)

Long-term solution?

* Update the configuration process to look for the ruby.pc file

and

* Do what the configure output says and use RbConfig rather than Config to extract the necessary information.

Because tdebindings has built for everybody in the past, I'm thinking the solution is first look for ruby.pc. When found then use that information to build the package. When ruby.pc is not found, which is true for versions < 1.9.3, then use the existing method to extract the ruby installation locations, which has proven to work.

With that said, I have no idea how to do that.

Not to mention that when we fix this, we need to test the patch against ruby 1.9.3, 1.9.1 and 1.8.x. :-(

I'll open a bug report but appreciate any comments.

Darrell