On 26 Jun 2012, Timothy Pearson stated:

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.

Er, this is a variable (arch-dependent) string. e.g. on my system it is

/usr/include/ruby-1.9.1/x86_64-linux

Clearly the Ruby build system has some way of returning the include path required to build programs that embed the Ruby interpreter. Looking at some other program that embeds Ruby should make it clear what that is. (I'd look, but it's mercilessly hot here and I haven't slept for days, so I'm feeling decidedly lazy...)

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