+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 <mke...@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.
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
