All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>,
	openembedded-devel@lists.openembedded.org
Subject: Re: ruby-native problem (on dylan)
Date: Fri, 4 Oct 2013 16:13:40 +0200	[thread overview]
Message-ID: <20131004141340.GF6240@jama> (raw)
In-Reply-To: <CAP71WjzY7STw_W1Zt2Lkg1D-GmZaxfGe_O37+tiH2wa6Bz4Vqg@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2013-10-04 14:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2013-11-04 15:43 ` Tobias Henkel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131004141340.GF6240@jama \
    --to=martin.jansa@gmail.com \
    --cc=nicolas.dechesne@linaro.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.