From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Issues with cross-compiling from x86_64 to a different x86_64
Date: Wed, 20 Jul 2016 00:01:54 +0200 [thread overview]
Message-ID: <20160720000154.4132543d@free-electrons.com> (raw)
In-Reply-To: <34C69F44FE4EA4498813EAECDBF40C1623A46E39@GUSALE0B.na.utcmail.com>
Hello,
First of all, thanks for your report!
On Tue, 19 Jul 2016 18:13:31 +0000, Arguin, Christopher P UTAS
wrote:
> I think I've uncovered a bug where targeting special instruction sets within the x86_64 family is not always getting treated as a cross-compile.
>
> I'm targeting a 4th Gen i7 board. We had everything working, but had the generic "nocona" architecture instead of the more specific 'core-avx2'. Our application would benefit from the AVX2 instruction set, so I switched it. After switching everything built fine on my laptop, which also happens to be a 4th Gen i7.
>
> I then migrated my build environment onto our build server, which is Xeon processor based. Suddenly the build starting failing with "illegal instruction" errors during the compile process. I switched the target architecture back to "nocona" and everything works in both environments.
>
> The only change between working and not-working is this entry in the config file:
> BR2_x86_core_avx2=y
>
> Currently there are two failure points, the second of which is fatal. A full working build takes about 61 minutes and the failing build took 52 minutes, so it got through most of the stuff before giving up.
>
> The first sign of problems occurs when building openssl, and it may be that it is incorrectly trying to use just-built code to generate or verify certificates:
> Doing certs/demo
> Illegal instruction (core dumped)
> Illegal instruction (core dumped)
> WARNING: Skipping duplicate certificate pca-cert.pem
> Illegal instruction (core dumped)
> WARNING: Skipping duplicate certificate ca-cert.pem
> Illegal instruction (core dumped)
>
>
> The second failure is on ncftp, and it fails immediately and catastrophically, as if the compiler is not working at all:
> Makefile:62: recipe for target 'DStrFree.o' failed
> make[4]: *** [DStrFree.o] Illegal instruction (core dumped)
> make[4]: *** Waiting for unfinished jobs....
> Makefile:62: recipe for target 'strtokc.o' failed
> make[4]: *** [strtokc.o] Illegal instruction (core dumped)
> Makefile:62: recipe for target 'Strncpy.o' failed
> make[4]: *** [Strncpy.o] Illegal instruction (core dumped)
> Makefile:62: recipe for target 'Strnpcpy.o' failed
> make[4]: *** [Strnpcpy.o] Illegal instruction (core dumped)
> Makefile:62: recipe for target 'StrFree.o' failed
> make[4]: *** [StrFree.o] Illegal instruction (core dumped)
> Makefile:62: recipe for target 'DStrCpyList.o' failed
> make[4]: *** [DStrCpyList.o] Illegal instruction (core dumped)
> Makefile:62: recipe for target 'Strncat.o' failed
> make[4]: *** [Strncat.o] Illegal instruction (core dumped)
> Makefile:62: recipe for target 'DStrCpy.o' failed
> make[4]: *** [DStrCpy.o] Illegal instruction (core dumped)
> Makefile:62: recipe for target 'DStrInit.o' failed
> make[4]: *** [DStrInit.o] Illegal instruction (core dumped)
> Makefile:32: recipe for target 'libs' failed
> make[3]: *** [libs] Error 2
I've just built the following defconfig:
BR2_x86_64=y
BR2_x86_core_avx2=y
BR2_PACKAGE_NCFTP=y
On a Xeon machine:
$ cat /proc/cpuinfo | grep "model name"
model name : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz
model name : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz
model name : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz
model name : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz
model name : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz
model name : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz
model name : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz
model name : Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz
And it built just fine.
Could you provide us a minimal configuration, which exhibits the ncftp
problem in your case?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-07-19 22:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 18:13 [Buildroot] Issues with cross-compiling from x86_64 to a different x86_64 Arguin, Christopher P UTAS
2016-07-19 22:01 ` Thomas Petazzoni [this message]
2016-07-20 2:07 ` [Buildroot] [External] " Arguin, Christopher P UTAS
2016-07-20 2:49 ` Arguin, Christopher P UTAS
2016-07-20 20:02 ` Thomas Petazzoni
2016-07-20 23:12 ` Arguin, Christopher P UTAS
2016-07-21 7:22 ` Thomas Petazzoni
2016-07-21 11:28 ` Romain NAOUR
2016-07-22 0:16 ` Arguin, Christopher P UTAS
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=20160720000154.4132543d@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--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