* ruby-native problem (on dylan)
@ 2013-10-04 8:09 Nicolas Dechesne
2013-10-04 10:09 ` Martin Jansa
2013-11-04 15:43 ` Tobias Henkel
0 siblings, 2 replies; 7+ messages in thread
From: Nicolas Dechesne @ 2013-10-04 8:09 UTC (permalink / raw)
To: openembedded-devel, Martin Jansa, Paul Eggleton
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:
$ 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/
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ruby-native problem (on dylan)
2013-10-04 8:09 ruby-native problem (on dylan) Nicolas Dechesne
@ 2013-10-04 10:09 ` Martin Jansa
2013-10-04 11:57 ` Nicolas Dechesne
2013-11-04 15:43 ` Tobias Henkel
1 sibling, 1 reply; 7+ messages in thread
From: Martin Jansa @ 2013-10-04 10:09 UTC (permalink / raw)
To: Nicolas Dechesne; +Cc: Paul Eggleton, openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 3493 bytes --]
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@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ruby-native problem (on dylan)
2013-10-04 10:09 ` Martin Jansa
@ 2013-10-04 11:57 ` Nicolas Dechesne
2013-10-04 13:22 ` Martin Jansa
0 siblings, 1 reply; 7+ messages in thread
From: Nicolas Dechesne @ 2013-10-04 11:57 UTC (permalink / raw)
To: Martin Jansa; +Cc: Paul Eggleton, openembedded-devel
On Fri, Oct 4, 2013 at 12:09 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> 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.
yes, it is working fine with this change.
however, don't you think that this is just a workaround? the real
issue being that ruby has hard coded paths?
thanks
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ruby-native problem (on dylan)
2013-10-04 11:57 ` Nicolas Dechesne
@ 2013-10-04 13:22 ` Martin Jansa
2013-10-04 13:26 ` Nicolas Dechesne
0 siblings, 1 reply; 7+ messages in thread
From: Martin Jansa @ 2013-10-04 13:22 UTC (permalink / raw)
To: Nicolas Dechesne; +Cc: Paul Eggleton, openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 1356 bytes --]
On Fri, Oct 04, 2013 at 01:57:06PM +0200, Nicolas Dechesne wrote:
> On Fri, Oct 4, 2013 at 12:09 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > 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.
>
> yes, it is working fine with this change.
>
> however, don't you think that this is just a workaround? the real
> issue being that ruby has hard coded paths?
qmake also has hard coded paths inside and we depend on qt.conf
overrides to set correct paths when building on host with different
paths to sysroot.
I think that only better solution is to patch ruby/qmake to remove the
support for "default" paths hard coded in binary and to always show an
error when correct paths aren't supplied by env variable or some cmdline
param.
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ruby-native problem (on dylan)
2013-10-04 13:22 ` Martin Jansa
@ 2013-10-04 13:26 ` Nicolas Dechesne
2013-10-04 14:13 ` Martin Jansa
0 siblings, 1 reply; 7+ messages in thread
From: Nicolas Dechesne @ 2013-10-04 13:26 UTC (permalink / raw)
To: Martin Jansa; +Cc: Paul Eggleton, openembedded-devel
On Fri, Oct 4, 2013 at 3:22 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> qmake also has hard coded paths inside and we depend on qt.conf
> overrides to set correct paths when building on host with different
> paths to sysroot.
well, gcc too in fact, since it has hardcoded sysroot ...
>
> I think that only better solution is to patch ruby/qmake to remove the
> support for "default" paths hard coded in binary and to always show an
> error when correct paths aren't supplied by env variable or some cmdline
> param.
i think that's what --enable-load-relative does in ruby ./configure.
i wonder what happens on ruby on the target then. i guess the standard
/usr/lib/xxx might be used by default.. but i haven't tried that.
can you make a similar patch on the dylan branch too?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: ruby-native problem (on dylan)
2013-10-04 13:26 ` Nicolas Dechesne
@ 2013-10-04 14:13 ` Martin Jansa
0 siblings, 0 replies; 7+ messages in thread
From: Martin Jansa @ 2013-10-04 14:13 UTC (permalink / raw)
To: Nicolas Dechesne; +Cc: Paul Eggleton, openembedded-devel
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
On Fri, Oct 04, 2013 at 03:26:21PM +0200, Nicolas Dechesne wrote:
> On Fri, Oct 4, 2013 at 3:22 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > qmake also has hard coded paths inside and we depend on qt.conf
> > overrides to set correct paths when building on host with different
> > paths to sysroot.
>
> well, gcc too in fact, since it has hardcoded sysroot ...
>
> >
> > I think that only better solution is to patch ruby/qmake to remove the
> > support for "default" paths hard coded in binary and to always show an
> > error when correct paths aren't supplied by env variable or some cmdline
> > param.
>
> i think that's what --enable-load-relative does in ruby ./configure.
>
> i wonder what happens on ruby on the target then. i guess the standard
> /usr/lib/xxx might be used by default.. but i haven't tried that.
>
> can you make a similar patch on the dylan branch too?
Yes will do in next round.
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* ruby-native problem (on dylan)
2013-10-04 8:09 ruby-native problem (on dylan) Nicolas Dechesne
2013-10-04 10:09 ` Martin Jansa
@ 2013-11-04 15:43 ` Tobias Henkel
1 sibling, 0 replies; 7+ messages in thread
From: Tobias Henkel @ 2013-11-04 15:43 UTC (permalink / raw)
To: openembedded-devel
Hello,
On 10/04/2013 10:09 AM, 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:
>
> $ 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.
I saw the same issue in my setup and looked a bit deeper into it.
The patch "ruby-1.9.3-custom-rubygems-location.patch" seems to break
--enable-load-relative.
When I remove this patch and add "--enable-load-relative" then ruby
starts without an error. But this has the side effect that the rubygems
directory is /usr/lib/ruby/rubygems instead of /usr/share/rubygems
inside the sysroot. I don't know if this matters. Would it break
anything else?
>
> 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/
>
Best Regards
Tobias
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-11-04 15:43 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-04 8:09 ruby-native problem (on dylan) Nicolas Dechesne
2013-10-04 10:09 ` Martin Jansa
2013-10-04 11:57 ` Nicolas Dechesne
2013-10-04 13:22 ` Martin Jansa
2013-10-04 13:26 ` Nicolas Dechesne
2013-10-04 14:13 ` Martin Jansa
2013-11-04 15:43 ` Tobias Henkel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.