| Message ID | 20220928221320.1763684-2-danismostlikely@gmail.com |
|---|---|
| State | Accepted, archived |
| Commit | 52b952e474e655f8b4b6501813d57e20c9f02ba2 |
| Headers | show |
| Series | [1/3] coreutils: add openssl PACKAGECONFIG | expand |
On 28 Sep 2022, at 23:13, Dan McGregor via lists.openembedded.org <danismostlikely=gmail.com@lists.openembedded.org> wrote: > > From: Daniel McGregor <daniel.mcgregor@vecima.com> > > The default x86-64 architecture for target gcc (ie, the one in poky > build appliances) is native. Since we have a variety of build systems > it will occasionally produce instructions that don't work on all of > our development system. > > Instead, set gcc's default architecture to the one specified in > TUNE_CC_ARCH, that guarantees that gcc-runtime and any binaries > produced are compatible with the target machine type. Can you explain the use-case here? These are target binaries, so why is the development system relevant? Ross
> On 29 Sep 2022, at 16:31, Daniel McGregor <daniel.mcgregor@vecima.com> wrote: > > Sure, I'm actually talking about host binaries, built inside our equivalent of a poky build appliance. The most obvious example is pseudo-native built on our newest build servers. GCC decides to use instructions (in particular BMI2 instructions) that don't exist on our older build machines. Since we use a common shared state and uninative it was becoming pretty common for old machines to pull shared state built on a much newer one, leading to build failures do to invalid opcode exceptions. Ah, so you build a container with Yocto and then do your Yocto builds inside that container. Got it, thanks. Ross
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc index 2abc0e355d7..d3b36937bf4 100644 --- a/meta/recipes-devtools/gcc/gcc-common.inc +++ b/meta/recipes-devtools/gcc/gcc-common.inc @@ -32,6 +32,16 @@ def get_gcc_float_setting(bb, d): get_gcc_float_setting[vardepvalue] = "${@get_gcc_float_setting(bb, d)}" +def get_gcc_x86_64_arch_setting(bb, d): + import re + march = re.match(r'^.*-march=([^\s]*)', d.getVar('TUNE_CCARGS')) + if march: + return "--with-arch=%s " % march.group(1) + # The earliest supported x86-64 CPU + return "--with-arch=core2" + +get_gcc_x86_64_arch_setting[vardepvalue] = "${@get_gcc_x86_64_arch_setting(bb, d)}" + def get_gcc_mips_plt_setting(bb, d): if d.getVar('TRANSLATED_TARGET_ARCH') in [ 'mips', 'mipsel' ] and bb.utils.contains('DISTRO_FEATURES', 'mplt', True, False, d): return "--with-mips-plt" diff --git a/meta/recipes-devtools/gcc/gcc-target.inc b/meta/recipes-devtools/gcc/gcc-target.inc index cc65e995c30..7dac3ef422c 100644 --- a/meta/recipes-devtools/gcc/gcc-target.inc +++ b/meta/recipes-devtools/gcc/gcc-target.inc @@ -19,7 +19,7 @@ EXTRA_OECONF:append:armv6:class-target = " --with-arch=armv6${ARMFPARCHEXT}" EXTRA_OECONF:append:armv7a:class-target = " --with-arch=armv7-a${ARMFPARCHEXT}" EXTRA_OECONF:append:armv7ve:class-target = " --with-arch=armv7ve${ARMFPARCHEXT}" EXTRA_OECONF:append:arc:class-target = " --with-cpu=${TUNE_PKGARCH}" -EXTRA_OECONF:append:x86-64:class-target = " --with-arch=native" +EXTRA_OECONF:append:x86-64:class-target = " ${@get_gcc_x86_64_arch_setting(bb, d)}" # libcc1 requres gcc_cv_objdump when cross build, but gcc_cv_objdump is # set in subdir gcc, so subdir libcc1 can't use it, export it here to