From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] dependencies/cmake: blacklist cmake 3.7
Date: Mon, 27 Feb 2017 18:41:10 +0100 [thread overview]
Message-ID: <20170227174110.GB17670@free.fr> (raw)
In-Reply-To: <20170227173117.xjxcxv4r5vb2dlub@tarshish>
Baruch, All,
On 2017-02-27 19:31 +0200, Baruch Siach spake thusly:
> On Mon, Feb 27, 2017 at 06:25:40PM +0100, Yann E. MORIN wrote:
> > On 2017-02-27 18:12 +0100, J?rg Krause spake thusly:
> > > On Sun, 2017-02-26 at 23:42 +0100, Yann E. MORIN wrote:
> > > > cmake-3.7 has a bug in how it handles rpath, linking with libraries
> > > > from
> > > > the host.
> > > >
> > > > Until we completely understand the issue, just blacklist cmake-3.7.
> > > >
> > > > The issue has been reported upstream:
> > > > ????http://public.kitware.com/pipermail/cmake/2017-February/064970.ht
> > > > ml
> > >
> > > Brad King from Kitware replied today [1]. In short, Brad does not think
> > > there anything wrong about handling the rpath and supposes to load a
> > > custom platform cmake file instead of the Linux one.
> > >
> > > [1] http://public.kitware.com/pipermail/cmake/2017-February/065063.html
> >
> > OK, so what we would have to do (basically):
> >
> > - copy Modules/Platform/Linux.cmake to Modules/Platform/Buildroot.cmake
> >
> > - tweak that file so that the two settings (lib32 and lib64) are now
> > FALSE in that file
> >
> > - tweak our support/misc/toolchain.cmake to set(CMAKE_SYSTEM_NAME Buildroot)
> >
> > and we'd be all good?
> >
> > Or alternatively:
> >
> > - add Modules/Platform/Buildroot.cmake, which:
> > - includes Modules/Platform/Linux.cmake
> > - sets the the two settings (lib32 and lib64) to FALSE
> >
> > - tweak our support/misc/toolchain.cmake to set(CMAKE_SYSTEM_NAME Buildroot)
> >
> > Thoughts?
>
> Again, what about host installed cmake?
And this is exactly the kind of reply I expected! ;-)
> Can we set lib{32,64} to FALSE
> directly in toolchain.cmake?
I don't think so...
The toolchainfile.cmake sets CMAKE_SYSTEM_NAME, which is used to find
the appropriate SystemName module. It means the SystemName.cmake file
can only be parsed after tolchainfile.cmake is.
So, anything we set in toolchainfile.cmake would be overriden by the
settings in the SystemName.cmake file.
Ergo, we're screwed in this case...
Unless we can tell cmake to look for modules in alternate locations.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2017-02-27 17:41 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 [this message]
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
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=20170227174110.GB17670@free.fr \
--to=yann.morin.1998@free.fr \
--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