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: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
