All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] CMAKE_SYSROOT issue [was: Re: [PATCH] toolchain-external: fix potential entire root filesystem removal]
Date: Wed, 21 Sep 2016 21:26:59 +0200	[thread overview]
Message-ID: <20160921192659.GD3405@free.fr> (raw)
In-Reply-To: <878tuscjlr.fsf@dell.be.48ers.dk>

Peter, All,

On 2016-09-16 10:52 +0200, Peter Korsgaard spake thusly:
> >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> 
>  > On 15-09-16 23:21, Peter Korsgaard wrote:
>  >>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
>  >> >> >  But nothing is really screaming that it should be included.
>  >> >> 
>  >> >> Ok. We should probably figure out if we need to revert the CMAKE_SYSROOT
>  >> >> addition (e8c3755676) and include that if needed.
>  >> 
>  >> >  Er, why would we need to revert it? Did I miss something?
>  >> 
>  >> I thought it had been discussed on the list, but apparently not. We got
>  >> a report on IRC (I unfortunately don't have logs) that builds of custom
>  >> packages using cmake were failing with 2016.08. It is apparently caused
>  >> by CMAKE_SYSROOT transforming -I$STAGING_DIR/usr/include into --sysroot
>  >> $STAGING_DIR -I /usr/include. In 2016.08 we now default
>  >> BR2_COMPILER_PARANOID_UNSAFE_PATH to y, so it complains about it.
> 
>  >  OK, I found it in my logs:
> 
> Thanks!
> 
>  >> [02/09 11:17:31] <smartin> cmake seems to split it like this:
>  >> '--sysroot <STAGING_DIR> -I/urs/include' , i guess cmake does it
>  >> because of/based on the CMAKE_SYSROOT.
>  >> [02/09 11:17:57] <smartin> ^^^ is to be confirm with cmake developers
>  >> [02/09 11:18:45] <smartin> but i wonder why it keep '-I/usr/include'
>  >> since it is a standard location that gcc will check anyway
>  >> [02/09 11:19:02] <smartin> ^^^ also, to be figured out with cmake developers
> 
> Samuel, did you hear back from the cmake devs?

From what I recal, there was no issue with our cmake infra as it is now.

The problem lies in websocketpp's CMakeList.txt which is incorrect and
forcefully adds /usr/include.

I even sent a PR upstream to fix the issue:

    https://github.com/zaphoyd/websocketpp/pull/578

Unfortunately, it seems the websocketpp hasn't had any activity since
last February: no commit, no PR review, no comment on issues...

But there is now a patch that Pieter can use when he submits
websocketpp.

So, after discussing the issue on IRC with Samuel, I believe this is a
non-issue in our infra.

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.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2016-09-21 19:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-15  8:58 [Buildroot] [PATCH] toolchain-external: fix potential entire root filesystem removal Thomas Petazzoni
2016-09-15 10:04 ` Peter Korsgaard
2016-09-15 16:35   ` Arnout Vandecappelle
2016-09-15 20:07     ` Peter Korsgaard
2016-09-15 20:58       ` Arnout Vandecappelle
2016-09-15 21:21         ` Peter Korsgaard
2016-09-16  7:42           ` [Buildroot] CMAKE_SYSROOT issue [was: Re: [PATCH] toolchain-external: fix potential entire root filesystem removal] Arnout Vandecappelle
2016-09-16  8:52             ` Peter Korsgaard
2016-09-21 19:26               ` Yann E. MORIN [this message]
2016-09-21 21:55                 ` Peter Korsgaard
2016-09-15 19:22   ` [Buildroot] [PATCH] toolchain-external: fix potential entire root filesystem removal Thomas Petazzoni
2016-09-15 20:08     ` Peter Korsgaard
2016-09-15 16:19 ` Arnout Vandecappelle
2016-09-15 19:20   ` Thomas Petazzoni
2016-09-16 10:13     ` Mason

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=20160921192659.GD3405@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 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.