Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Romain Naour <romain.naour@openwide.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [v3, 12/12] Add option for paranoid unsafe path checking
Date: Sat, 13 Dec 2014 17:37:59 +0100	[thread overview]
Message-ID: <548C6B67.20707@openwide.fr> (raw)
In-Reply-To: <1418485730.2167.11.camel@posteo.de>

Hi J?rg,

Le 13/12/2014 16:48, J?rg Krause a ?crit :
> On Sa, 2014-12-13 at 16:17 +0100, Romain Naour wrote:
>> Hi J?rg,
>>
>> Le 13/12/2014 15:11, J?rg Krause a ?crit :
>>> On Sa, 2014-12-13 at 01:19 +0100, Romain Naour wrote:
>>>> Hello J?rg,
>>>>
>>>> Le 13/12/2014 01:04, J?rg Krause a ?crit :
>>>>> Hi Romain Naour,
>>>>>
>>>>> what should I do if a package build fails because of an unsafe path
>>>>> error? Propose a patch for the package?
>>>>>
>>>>
>>>> Yes, you needs patch the package's build system to remove the host path.
>>>
>>> Many thanks! So hostpad and wpa_supplicant need patches.
>>
>> You're welcome.
> 
> Many thanks for the invitation :)
> 
>> I didn't know that these packages were problems with the paranoid wrapper.
> 
> make[1]: Entering directory
> '/home/joerg/Work/buildroot/output/build/wpa_supplicant-2.3/wpa_supplicant'
> arm-linux-gcc: WARNING: unsafe header/library path used in
> cross-compilation: '/usr/include/libnl3'

Ok, this is bad :)

> 
>>
>>>
>>>>
>>>> This error appear if one of the following paths is used during the
>>>> cross-compilation:
>>>> "/lib"
>>>> "/usr/include"
>>>> "/usr/lib"
>>>> "/usr/local/include"
>>>> "/usr/local/lib"
>>>
>>> One more question: Why are these pathes unsafe for cross-compilation?
>>
>> You have a good example here: 
>> http://autobuild.buildroot.net/results/da0/da018caa1b79369bdff41d23b8696bc673625e1b/build-end.log
>>
>> perl-gd try to link with the host (x86_64) libraries wile cross-compiling for mipsel target.
>> It also include host headers path /usr/include
>>
>> This is this kind of error we want to avoid before adding a new package or bumping version.
>>
> I see. So instead of eg "/usr/include" "/include" should be used? And
> instead of "/lib" "/"?
> 

No, we need to include headers from STAGING_DIR.
So, instead of "/usr/include" we need to have "$(STAGING_DIR)/usr/include/"

see "--include=$(STAGING_DIR)/usr/include":
http://git.buildroot.net/buildroot/tree/package/sed/sed.mk

Best regards,
-- 
Romain Naour

OPEN WIDE Ing?nierie - Paris
23/25, rue Daviel| 75013 PARIS
http://ingenierie.openwide.fr

Le blog des technologies libres et embarqu?es :
http://www.linuxembedded.fr

  reply	other threads:[~2014-12-13 16:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-13  0:04 [Buildroot] [v3, 12/12] Add option for paranoid unsafe path checking Jörg Krause
2014-12-13  0:19 ` Romain Naour
2014-12-13 14:11   ` Jörg Krause
2014-12-13 15:17     ` Romain Naour
2014-12-13 15:48       ` Jörg Krause
2014-12-13 16:37         ` Romain Naour [this message]
2014-12-13 16:46         ` Samuel Martin

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=548C6B67.20707@openwide.fr \
    --to=romain.naour@openwide.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