By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 1070 - Build issue: tdebindings FTBFS with ruby 1.9.3
Summary: Build issue: tdebindings FTBFS with ruby 1.9.3
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: non-core programs (show other bugs)
Version: R14.0.0 [Trinity]
Hardware: Other Linux
: P1 critical
Assignee: Slávek Banko
URL:
Depends on:
Blocks:
 
Reported: 2012-06-26 22:02 CDT by Darrell
Modified: 2012-10-19 15:41 CDT (History)
3 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:


Attachments
Fix build with ruby 1.9.x without pkgconfig file (1.27 KB, patch)
2012-10-12 09:31 CDT, Slávek Banko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darrell 2012-06-26 22:02:42 CDT
Although bug report 597 exists to address certain build issues with ruby 1.9.x, I'm filing a new report to address build failures with 1.9.3 or newer. Although I'm building in Slackware Current (soon to be Slackware 14), I believe this failure will affect anybody who has ruby 1.9.3 installed.

The failure:

In file included from /usr/include/ruby-1.9.1/ruby.h:32:0,
                 from Qt.cpp:49:
/usr/include/ruby-1.9.1/ruby/ruby.h:24:25: fatal error: ruby/config.h: No such file or directory
compilation terminated.
make[5]: *** [Qt.lo] Error 1


The oddity is no such failure on Slackware 13.1 or 13.37, 32 or 64 bit. The config.h file is installed in the same place on all systems. For 32-bit that location is /usr/include/ruby-1.9.1/i486-linux/ruby. For 64-bit that location is /usr/include/ruby-1.9.1/x86_64-linux/ruby.

In an attempt to resolve the problem, in my build script I added the following:

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} \
  ...

Using the --with-extra-includes configure option allowed tdebindings to build as usual.

Recently we patched tdebindings to detect ruby versions differently between 1.8.x and 1.9.x (commit b2e0df6c).

With that in mind, possibly I stumbled across what is happening with the recent build failure.

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 suspect 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. Below is a copy of 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, the ruby.pc file changes arch=x86_64-linux and libdir=/usr/lib64.

Short-term solution?

For 32-bit use:

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

For 64-bit use:

--with-extra-include=/usr/include/ruby-1.9.1/x86_64-linux

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 new 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. :-(

By the way, I have no idea why ruby version 1.9.3 installs header files to /usr/include/ruby-1.9.1, but I confirmed that this is the way ruby 1.9.3 is packaged. Also notice the ruby.pc file, which also references 1.9.1. Perhaps the ruby people have some good rope to smoke. :-)
Comment 1 Darrell 2012-06-26 22:03:51 CDT
I tagged the severity as Critical rather than Blocker because there is a work-around: using --with-extra-includes.
Comment 2 Timothy Pearson 2012-09-11 11:41:42 CDT
Fix pushed to GIT in hash de49c74.

Please let me know if the build now succeeds, or if additional work needs to be done.

Thanks!
Comment 3 Timothy Pearson 2012-09-11 11:58:13 CDT
GIT hash c1faffb adds the ability to use the ruby .pc file to determine cflags.
Comment 4 Darrell 2012-09-17 11:35:40 CDT
The following tests fail on Slackware 14 because ruby-1.9.pc exists rather than ruby.pc. (There is no ruby.pc sym link.)

RUBY_VERSION=`$PKGCONFIG ruby --modversion`
RUBY_CFLAGS=`$PKGCONFIG ruby --cflags`
Comment 5 Darrell 2012-09-18 14:17:33 CDT
Confirmed: tdebindings builds on Slackware 14 with ruby 1.9.3 but needs an additional patch:

AS IS:
RUBY_VERSION=`$PKGCONFIG ruby --modversion`
RUBY_CFLAGS=`$PKGCONFIG ruby --cflags`

CHANGE TO:
RUBY_VERSION=`$PKGCONFIG ruby-1.9 --modversion`
RUBY_CFLAGS=`$PKGCONFIG ruby-1.9 --cflags`
Comment 6 Darrell 2012-10-11 23:52:08 CDT
I believe this bug report may be closed as resolved with commit 2712dc64 from 2012-09-30. I can build tdebindings in Slackware 13.1 with ruby 1.9.1 and Slackware 14 with ruby 1.9.3.
Comment 7 Slávek Banko 2012-10-12 01:24:56 CDT
I'm doing the building on Ubuntu Quantal with ruby ​​1.9.3 from distribution. This not contain ruby.pc or ruby-1.9.pc. Thanks to commit 2712dc64 configure correctly respond to this state, except RUBY_CFLAGS that remain empty. Building then ends with error:

In file included from libqtrubyinternal_la.all_cpp.cpp:2:0:
Qt.cpp:49:18: fatal error: ruby.h: No such file or directory
Comment 8 Slávek Banko 2012-10-12 09:31:00 CDT
Created attachment 875 [details]
Fix build with ruby 1.9.x without pkgconfig file

Note: If absence pkgconfig file is the only reason to maintain their own version of ruby in build-deps, this patch could be handier solution.
Comment 9 Darrell 2012-10-12 11:43:59 CDT
I will test the patch against ruby 1.9.1 and 1.9.3. 1.9.1 never had a pc file. On my system 1.9.3 does. So if the patch works with both and works with your setup, then we're probably okay. :)
Comment 10 Slávek Banko 2012-10-12 19:15:44 CDT
Attachment 875 [details] pushed to GIT in hash 115acc39.