Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörg Krause" <joerg.krause@embedded.rocks>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] dependencies/cmake: blacklist cmake 3.7
Date: Mon, 27 Feb 2017 21:56:10 +0100	[thread overview]
Message-ID: <1488228970.14030.9.camel@embedded.rocks> (raw)
In-Reply-To: <20170227200827.GA14356@megas.kitware.com>

Hi Ben,

On Mon, 2017-02-27 at 15:08 -0500, Ben Boeckel wrote:
> On Mon, Feb 27, 2017 at 21:04:06 +0100, J?rg Krause wrote:
> > I still think this is a bug! A host rpath should not be used when
> > cross-compiling whether lib32 is used or not. Somehow, it feels
> > weird
> > to say that Buildroot is not a Linux platform, in the sense of
> > CMake.
> 
> There's the chance that this was always a problem, but is now being
> exposed by this. Where is the lib32 rpath coming from? CMake doesn't
> add
> rpaths by default, so it has to be coming from somewhere. Is it added
> manually somewhere? Is a library that used to be found in the sysroot
> now being found on the host? If so, *that's* the bug which should be
> fixed. Given how widespread it is, maybe something is set up
> incorrectly
> in the toolchain file?
> 
> This flag is the same logic as lib64, just with a different suffix.
> Why
> is the problem not surfacing on Red Hat platforms which use lib64?

Note, that the build errors depend on the host system. I was able to
reproduce the build errors on a Debian system, whereas on a Arch, the
build does not break. However, all system are affected by having a
rpath set to a host path. It just not break the build on all host
systems. I did not investigated why...

  parent reply	other threads:[~2017-02-27 20:56 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-26 22:42 [Buildroot] [PATCH] dependencies/cmake: blacklist cmake 3.7 Yann E. MORIN
2017-02-27  4:43 ` Baruch Siach
2017-02-27 15:51   ` Yann E. MORIN
2017-02-27 17:12 ` Jörg Krause
2017-02-27 17:25   ` Yann E. MORIN
2017-02-27 17:31     ` Baruch Siach
2017-02-27 17:41       ` Yann E. MORIN
2017-02-27 18:30     ` Yann E. MORIN
2017-02-27 18:35       ` Ben Boeckel
2017-02-27 20:59         ` Yann E. MORIN
2017-02-27 21:13           ` Jörg Krause
2017-02-27 20:53       ` Yann E. MORIN
2017-02-27 21:02         ` Jörg Krause
2017-02-27 20:04     ` Jörg Krause
2017-02-27 20:08       ` Ben Boeckel
2017-02-27 20:24         ` Jörg Krause
2017-02-27 20:40           ` Ben Boeckel
2017-02-27 20:56         ` Jörg Krause [this message]
2017-02-28  8:51 ` Peter Korsgaard
2017-02-28 16:16   ` Yann E. MORIN
2017-02-28 16:38     ` Peter Korsgaard

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=1488228970.14030.9.camel@embedded.rocks \
    --to=joerg.krause@embedded.rocks \
    --cc=buildroot@busybox.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox