[oe] ruby-native problem (on dylan)
Martin Jansa
martin.jansa at gmail.com
Fri Oct 4 10:09:04 UTC 2013
On Fri, Oct 04, 2013 at 10:09:53AM +0200, Nicolas Dechesne wrote:
> hi,
>
> we got some build failures in our autobuilders last night, which
> seemed to be related to ruby-native. We use dylan, but I believe the
> same problem is there in master/dora too.
>
> The exact build error was in qtwebkit do_compile:
>
> ruby /mnt/ci_build/workspace/project/branches/dylan/label/oe_persistent_cloud/machines/genericarmv7a/build/tmp/work/armv7ahf-vfp-neon-project-linux-gnueabi/qtwebkit/5.0.2-r0.0/qtwebkit-opensource-src-5.0.2/Source/JavaScriptCore/offlineasm/generate_offset_extractor.rb
> /mnt/ci_build/workspace/project/branches/dylan/label/oe_persistent_cloud/machines/genericarmv7a/build/tmp/work/armv7ahf-vfp-neon-project-linux-gnueabi/qtwebkit/5.0.2-r0.0/qtwebkit-opensource-src-5.0.2/Source/JavaScriptCore/llint/LowLevelInterpreter.asm
> LLIntDesiredOffsets.h
>
> <internal:gem_prelude>:1:in `require': cannot load such file --
> rubygems.rb (LoadError)
> from <internal:gem_prelude>:1:in `<compiled>'
>
> Yesterday I had 'moved' our BUILDDIR location. However for every build, we:
> - delete the TMPDIR completely
> - reuse our sstate
>
> The problem seems to be that 'ruby' has hard coded paths in the
> binary. This is discussed in [1] or more at length in [2], and easy to
> check:
Try to add this in qtwebkit.inc:
# make sure rb files are used from sysroot, not from host
# ruby-1.9.3-always-use-i386.patch is doing target_cpu=`echo $target_cpu | sed s/i.86/i386/`
# we need to replace it too (a bit longer version without importing re)
RUBY_SYS = "${@ '${BUILD_SYS}'.replace('i486', 'i386').replace('i586', 'i386').replace('i686', 'i386') }"
export RUBYLIB="${STAGING_DATADIR_NATIVE}/rubygems:${STAGING_LIBDIR_NATIVE}/ruby:${STAGING_LIBDIR_NATIVE}/ruby/${RUBY_SYS}"
if you can confirm it works for you I'll push it to meta-qt5.
>
> $ strings tmp/sysroots/x86_64-linux/usr/bin/ruby | grep project
> /work/project/build/tmp/sysroots/x86_64-linux/usr
> /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby/site_ruby
> /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby/site_ruby/x86_64-linux
> /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby/vendor_ruby
> /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby/vendor_ruby/x86_64-linux
> /work/project/build/tmp/sysroots/x86_64-linux/usr/share/rubygems
> /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby
> /work/project/build/tmp/sysroots/x86_64-linux/usr/lib/ruby/x86_64-linux
>
> So, the 'ruby' binary which was in the sstate, knew about the *old*
> paths. When building today, ruby was pulled from sstate, but TMPDIR
> has changed now, and the hardcoded paths no longer exists, leading to
> the build failure.
>
> I verified that the following 'solved' the build issue:
> $ bitbake -c cleansstate ruby-native
> $ bitbake ruby-native
> $ bitbake qtwebkit
>
> There seems to be a configure option, --enable-load-relative, after
> using this option in ruby build, still ruby fails to start for the
> same reason. I might have done something wrong, but i wanted to bring
> it on the list, to see if anyone has a better solution, as it seems
> like a big issue.
>
> thanks
>
> nicolas
>
>
> [1] http://stackoverflow.com/questions/10221387/moving-ruby-installation-causes-it-to-not-function-how-to-get-around-this
> [2] http://yehudakatz.com/2012/06/
--
Martin 'JaMa' Jansa jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20131004/0b8d054d/attachment-0002.sig>
More information about the Openembedded-devel
mailing list