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
next prev parent 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