Package: meson Version: 0.48.1-1 User: helm...@debian.org Usertags: rebootstrap
Meson wrongly caches the result of a dependency() call. If you need a dependency for both the build architecture and host architecture, meson caches uses the results from the first invocation for the other invocation. Let me demonstrate the faulty behaviour with the following meson file: project('test', 'c') # The following dependency call is unnecessary here, but its results # leak into the next call. glib = dependency('glib-2.0') native_glib = dependency('glib-2.0', native: true) gen = executable('gen', 'gen.c', dependencies: [native_glib], native: true) out = custom_target('out', output: 'out', command: [gen], capture: true, build_by_default: true) To actually build it, you need some gen.c file: #include <stdio.h> int main() { printf("success\n"); return 0; } When cross building this project, the expected behaviour is generating a file called "out" with the "content" success". To reproduce, create a crossfile using /usr/share/meson/debcrossgen e.g. for ppc64el. Then running meson yields the following output: | WARNING: Unknown CPU family 'powerpc64le', please report this at https://github.com/mesonbuild/meson/issues/new | The Meson build system | Version: 0.48.1 | Source dir: .../source | Build dir: .../source/build | Build type: cross build | Project name: test | Project version: undefined | Native C compiler: cc (gcc 8.2.0 "cc (Debian 8.2.0-9) 8.2.0") | Cross C compiler: /usr/bin/powerpc64le-linux-gnu-gcc (gcc 8.2.0) | Host machine cpu family: powerpc64le | Host machine cpu: ppc64el | Target machine cpu family: powerpc64le | Target machine cpu: ppc64el | Build machine cpu family: x86_64 | Build machine cpu: x86_64 | Cross dependency glib-2.0 found: YES 2.58.1 | Native dependency glib-2.0 found: YES 2.58.1 | Build targets in project: 2 | Found ninja-1.8.2 at /usr/bin/ninja All looks well. Now run ninja -v. | [1/3] cc -Igen@exe -I. -I.. -I/usr/include/glib-2.0 -I/usr/lib/powerpc64le-linux-gnu/glib-2.0/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -g -MD -MQ 'gen@exe/gen.c.o' -MF 'gen@exe/gen.c.o.d' -o 'gen@exe/gen.c.o' -c ../gen.c | [2/3] cc -o gen 'gen@exe/gen.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group /usr/lib/powerpc64le-linux-gnu/libglib-2.0.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/../../usr/lib/powerpc64le-linux-gnu' -Wl,-rpath-link,/usr/lib/powerpc64le-linux-gnu | FAILED: gen | cc -o gen 'gen@exe/gen.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group /usr/lib/powerpc64le-linux-gnu/libglib-2.0.so -Wl,--end-group '-Wl,-rpath,$ORIGIN/../../usr/lib/powerpc64le-linux-gnu' -Wl,-rpath-link,/usr/lib/powerpc64le-linux-gnu | /usr/bin/ld: /usr/lib/powerpc64le-linux-gnu/libglib-2.0.so: error adding symbols: file in wrong format | collect2: error: ld returned 1 exit status | ninja: build stopped: subcommand failed. You notice that the native compiler invocation is asked to link the host architecture libglib-2.0.so. That's wrong. To see that this is actually the first depenency() call leaking into the next call, we can simply remove the first (unnecessary) call. After doing so, the sample project crosses fine. Helmut