I'm finding this build failure confusing. Hopefully somebody can shed some light. tdebindings builds without failure on Slackware 13.1 and 13.37, but fails on Slackware Current (soon to be Slackware 14). The problem is not gcc 4.7.1 related because this failure started before Current updated to 4.7.1 (only yesterday). I previously built tdebindings on Current a few weeks ago. What changed between then and now? Ruby was updated from 1.9.1 to 1.9.3 and that is the only related change I notice. That is what the failure message indicates too. In tdebindings/qtruby/rubylib/qtruby/Qt.cpp: #include <ruby.h> In ruby-1.9.1, ruby.h: #include "ruby/config.h" In ruby-1.9.3, ruby.h: #include "ruby/config.h" For both, config.h is installed at: /usr/include/ruby-1.9.1/i486-linux/ruby/config.h I don't know why ruby 1.9.3 uses ruby-1.9.1 as a parent directory rather than ruby-1.9.3. Could that be the problem? How do I work-around this failure? Darrell

On 26 Jun 2012, Timothy Pearson stated: 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...) -- NULL && (void)

I sent this message earlier today, but looks like the message disappeared while the server was disconnected from the world. 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