[1/1] package/meson: fix blank entry in cross-compilation.conf

Without this change, cross-compilation.conf seems to be generated with a
blank cpu entry in the host_machine section.  (Note: what meson calls host,
buildroot calls target.)

The effect is that meson-based packages may fail to detect architectural
features of the target CPU, like SSE support, and either fail to take
advantage of them or just refuse to compile.

This change follows the convention used to emit the `endian` entry in that
section, which comes from [92eca65ddf meson: Strip quotes from BR2_ENDIAN].
To verify: `grep cpu ./output/host/etc/meson/cross-compilation.conf`

Signed-off-by: Derrick Lyndon Pallas <derrick@meter.com>
---
 package/meson/meson.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Hello Derrick,

On Fri, 23 Oct 2020 06:12:51 +0000, Derrick Lyndon Pallas <derrick@meter.com> wrote:

> Without this change, cross-compilation.conf seems to be generated with a
> blank cpu entry in the host_machine section.  (Note: what meson calls host,
> buildroot calls target.)
>
> The effect is that meson-based packages may fail to detect architectural
> features of the target CPU, like SSE support, and either fail to take
> advantage of them or just refuse to compile.
>
> This change follows the convention used to emit the `endian` entry in that
> section, which comes from [92eca65ddf meson: Strip quotes from BR2_ENDIAN].
> To verify: `grep cpu ./output/host/etc/meson/cross-compilation.conf`

On my system (for a RPi4 configuration) already without your patch:

	$ grep cpu host/etc/meson/cross-compilation.conf
cpu_family ='aarch64'
cpu = 'cortex-a72'

>
> Signed-off-by: Derrick Lyndon Pallas <derrick@meter.com>
> ---
>  package/meson/meson.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/meson/meson.mk b/package/meson/meson.mk
> index d39e66cf05..9bccea8fef 100644
> --- a/package/meson/meson.mk
> +++ b/package/meson/meson.mk
> @@ -14,7 +14,7 @@ HOST_MESON_DEPENDENCIES = host-ninja
>  HOST_MESON_NEEDS_HOST_PYTHON = python3
>
>  HOST_MESON_TARGET_ENDIAN = $(call qstrip,$(call LOWERCASE,$(BR2_ENDIAN)))
> -HOST_MESON_TARGET_CPU = $(GCC_TARGET_CPU)
> +HOST_MESON_TARGET_CPU = $(call qstrip,$(call LOWERCASE,$(GCC_TARGET_CPU)))

GCC_TARGET_CPU comes from arch/arch.mk:

GCC_TARGET_CPU := $(call qstrip,$(BR2_GCC_TARGET_CPU))

Anything special with your configuration/build environment (which
buildroot version)? What is the BR2_GCC_TARGET_CPU entry in
your .config file?

Regards,
Peter

>
>  # https://mesonbuild.com/Reference-tables.html#cpu-families
>  ifeq ($(BR2_arcle)$(BR2_arceb),y)

Thanks for looking Peter.

On 10/24/20 11:32 AM, Peter Seiderer wrote:
> On my system (for a RPi4 configuration) already without your patch:
> 
> 	$ grep cpu host/etc/meson/cross-compilation.conf
> cpu_family ='aarch64'
> cpu = 'cortex-a72'
> 
> GCC_TARGET_CPU comes from arch/arch.mk:
> 
> GCC_TARGET_CPU := $(call qstrip,$(BR2_GCC_TARGET_CPU))
> 
> Anything special with your configuration/build environment (which
> buildroot version)? What is the BR2_GCC_TARGET_CPU entry in
> your .config file?

I've tried this on both the development branch and on 2020.08.1 and I 
get the same results. The target is an x86_64/silvermont. After taking a 
second look, the problem seems to be that arch/Config.in.x86 does not 
actually set BR2_GCC_TARGET_CPU; instead, it sets BR2_GCC_TARGET_ARCH 
with a value that might better described as BR2_GCC_TARGET_CPU. Thus, my 
config has

	BR2_ARCH = x86_64 # because BR2_x86_64
	BR2_GCC_TARGET_ARCH = silvermont # because BR2_x86_silvermont

Is the config variable misnamed for x86? Adding Thomas Petazzoni, since 
it looks like he did the original breakout of BR2_GCC_TARGET_ARCH and 
then later removed it from several archs (e.g. arm) in favor of cpu.

Or should there be a fallback from BR2_GCC_TARGET_CPU to 
BR2_GCC_TARGET_ARCH if the former does not exist?

Thanks, ~Derrick

Hello Derrick,

Le 24/10/2020 à 21:02, Derrick Pallas a écrit :
> Thanks for looking Peter.
> 
> On 10/24/20 11:32 AM, Peter Seiderer wrote:
>> On my system (for a RPi4 configuration) already without your patch:
>>
>>     $ grep cpu host/etc/meson/cross-compilation.conf
>> cpu_family ='aarch64'
>> cpu = 'cortex-a72'
>>
>> GCC_TARGET_CPU comes from arch/arch.mk:
>>
>> GCC_TARGET_CPU := $(call qstrip,$(BR2_GCC_TARGET_CPU))
>>
>> Anything special with your configuration/build environment (which
>> buildroot version)? What is the BR2_GCC_TARGET_CPU entry in
>> your .config file?
> 
> I've tried this on both the development branch and on 2020.08.1 and I get the
> same results. The target is an x86_64/silvermont. After taking a second look,
> the problem seems to be that arch/Config.in.x86 does not actually set
> BR2_GCC_TARGET_CPU; instead, it sets BR2_GCC_TARGET_ARCH with a value that might
> better described as BR2_GCC_TARGET_CPU. Thus, my config has
> 
>     BR2_ARCH = x86_64 # because BR2_x86_64
>     BR2_GCC_TARGET_ARCH = silvermont # because BR2_x86_silvermont
> 
> Is the config variable misnamed for x86? Adding Thomas Petazzoni, since it looks
> like he did the original breakout of BR2_GCC_TARGET_ARCH and then later removed
> it from several archs (e.g. arm) in favor of cpu.
> 
> Or should there be a fallback from BR2_GCC_TARGET_CPU to BR2_GCC_TARGET_ARCH if
> the former does not exist?

I don't see any change with this patch applied.

Indeed, cpu is empty on x86_64 architecture:

[host_machine]
system = 'linux'
cpu_family = 'x86_64'
cpu = ''
endian = 'little'

On aach64:

[host_machine]
system = 'linux'
cpu_family = 'aarch64'
cpu = 'cortex-a53'
endian = 'little'

See meson documentation about cpu_family vs cpu:
https://mesonbuild.com/Cross-compilation.html#machine-entries

Yocto use TARGET_ARCH as cpu value:

https://github.com/openembedded/openembedded-core/blob/dunfell/meta/classes/meson.bbclass#L119

Did you try to use BR2_GCC_TARGET_ARCH as cpu value ?
Did you notice any change/improvement ?

I not sure it's really annoying since Buildroot use a toolchain wrapper that
provide -mcpu= or -march= flag on the gcc command line.

Best regards,
Romain


> 
> Thanks, ~Derrick
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot