[OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

+CC Khem Raj, who has done a lot of work on the SDK and may have an 
opinion about handling relocatable cross files.

On 01/09/2018 01:50 AM, Nirbheek Chauhan wrote:
> On Tue, Jan 9, 2018 at 5:21 AM, Martin Kelly <mkelly at xevo.com> wrote:
>> [Jussi Pakkanen, Nirbheek Chauhan, I know you may not be on the list; I
>> added you to get Yocto/OE and meson upstream all on the same thread to
>> discuss integrating the two]
>>
>> Hi all,
>>
>> Recently, we got meson added to OE-core as part of Yocto (thanks Alexander
>> Kanavin!).
> 
> Great to hear that! Thanks for your work, Alexander :)
> 
> [snip]
>> - The cross-file does not support relocatable cross-tools. This is an issue
>> because OE SDKs are self-extracting shell scripts that can be installed
>> anywhere on a machine. Once installed, they populate the env with --sysroot=
>> and other flags pointing into the installed SDK location. For example, if I
>> install an ARM SDK into /tmp/sdk, I would get something like this:
>>
> 
> It does support that as of 0.43:
> 
> http://mesonbuild.com/Release-notes-for-0-43-0.html#can-override-executables-in-the-cross-file
> 
> I believe this should solve your problems with cross-tools at least.
> Note that this also works for pkg-config, g-ir-compiler, g-ir-scanner,
> etc.
> 

This sounds like the right idea, but in its current form I'm not sure if 
it will solve the problem. The issue I hit when building actually were 
not caused by anything in the meson build file itself; they were caused 
by the meson sanity checker. meson appears to assume that anything found 
in CC, CXX, etc. are all native tools:

$ . /tmp/sdk/environment-setup-cortexa7hf-neon-vfpv4-poky-linux-gnueabi

$ echo $CC
arm-poky-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon-vfpv4 
-mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/tmp/sdk/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi

$ meson --cross-file /tmp/meson.cross build .
The Meson build system
Version: 0.43.0
Source dir: /home/martin/xlib
Build dir: /home/martin/xlib/build
Build type: cross build
Project name: xlib
Native C compiler: arm-poky-linux-gnueabi-gcc -march=armv7ve -marm 
-mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/tmp/sdk/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi 
(gcc 7.2.0)
Appending CFLAGS from environment: ' -O2 -pipe -g 
-feliminate-unused-debug-types '
Appending LDFLAGS from environment: '-Wl,-O1 -Wl,--hash-style=gnu 
-Wl,--as-needed'
Cross C compiler: arm-poky-linux-gnueabi-gcc (gcc 7.2.0)
/home/martin/xlib/build/meson-private/sanitycheckcpp.exe: error while 
loading shared libraries: libstdc++.so.6: cannot open shared object 
file: No such file or directory

Meson encountered an error in file meson.build, line 1, column 0:
Executables created by cpp compiler arm-poky-linux-gnueabi-g++ 
-march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 
--sysroot=/tmp/sdk/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi are 
not runnable.

Note the "native C compiler" line, which directly uses $CC.

I'm not sure if this is correct, but an easy way to fix the issue is to 
ignore $CC for internal sanity checking when a cross file is specified. 
In that way, meson would probe the system and use the normal gcc for 
sanity checking while still using the cross file for the actual build.

>> $ echo $CC
>> arm-poky-linux-gnueabi-gcc -march=armv7ve -marm -mfpu=neon-vfpv4
>> -mfloat-abi=hard -mcpu=cortex-a7
>> --sysroot=/tmp/sdk/sysroots/cortexa7hf-neon-vfpv4-poky-linux-gnueabi
>>
>> If we want to setup a cross-file to use these arguments, we would have to
>> generate the cross-file on-the-fly (not good).
> 
> Out of interest, why is that not good? That is precisely what Gentoo
> does and it has to solve the same problems here that Yocto is facing.
> 

Right now, the SDK contains fixed contents, and there is some top-level 
logic for rewriting a few paths to make everything relocatable. I don't 
think OE wants to inject a special-case one-time generation of the 
toolchain file at SDK extraction time, as it circumvents the normal 
build process, which normally sets up the right environment for 
generating the right toolchain file. For example, cmake generates its 
toolchain as part of the build process and the SDK just extracts it 
without special knowledge of cmake or its contents. To my knowledge, 
nothing else in the OE special-cases its extraction logic, so it would 
be a special-case that would likely cause us problems in the future. At 
the very least, we would need to get more OE maintainers to voice an 
opinion on this.

Another approach would be to generate the toolchain file truly 
"on-the-fly", such that the meson command points to a script that first 
generates a toolchain file based on the contents of CC, CXX, etc. and 
then runs meson. I think this is a bad idea because it is complex (will 
definitely surprise people) and slow. It also breaks people in 
surprising ways when they accidentally use a meson from outside the SDK 
due to the PATH setup.