Cross-Compile query for binary execution on actual hardware

[Ali Tariq]

Hi everyone,

I am working on a project that uses the meson build system and ninja to compile source code and run tests on binaries.

Previously the project was compiled for native architecture but now I need to cross-compile it for running the tests on RISC-V architecture while compiling it on x86 machine.

The cross-compiler that I am using is riscv64-unknown-linux-gnu-gcc from the RISC-V GNU toolchain.

Following is my command which I used to set the build:

meson setup --cross-file riscv64-cross.txt build

Following is my riscv64-cross.txt file:

[binaries]
c = 'riscv64-unknown-linux-gnu-gcc'
cpp = 'riscv64-unknown-linux-gnu-g++'
ar = 'riscv64-unknown-linux-gnu-ar'
strip = 'riscv64-unknown-linux-gnu-strip'

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

Then I used the following command to build the source code:

ninja -C build -v

After that, I copied the whole project directory to the RISC-V instance and ran the following command to run tests:

ninja -C build -v test

But it is giving me following error:

riscv64-unknown-linux-gnu/12042024/sysroot/lib/libm.so.6', needed by 'test/common/common-c', missing and no known rule to make it

The path that it is showing is of the x86 compute instance. After checking the build. ninja file, it seems that meson stores the absolute path to cross compiler and tries to access the libraries (which are not available since I moved the project to RISC-V instance and tried to execute tests there). Is there a way to produce setup this in such a way that it cross-compiles source code for RISC-V and then I can execute the test on an actual RISC-V instance?

Regards,
Ali

[Jussi Pakkanen]

On Tue, 14 May 2024 at 23:20, Ali Tariq <ali....@10xengineers.ai> wrote:

> After that, I copied the whole project directory to the RISC-V instance and ran the following command to run tests:

Meson really does not like it if you move the contents of the build
directory around in the file system.

> Is there a way to produce setup this in such a way that it cross-compiles source code for RISC-V and then I can execute the test on an actual RISC-V instance?

Look up the documentation for "exe wrapper". That is an executable (or
script) you can define whose job is to run cross-built binaries.
Typically it is something like qemu but you can create your own runner
script that can do whatever you want, up to and including copying the
binary to some other piece of hw and running it there.

[Eli Schwartz]

On 5/14/24 4:20 PM, Ali Tariq wrote:
> Hi everyone,
> I am working on a project that uses the meson build system and ninja to
> compile source code and run tests on binaries.
>
> Previously the project was compiled for native architecture but now I need
> to cross-compile it for running the tests on RISC-V architecture while
> compiling it on x86 machine.

It's not clear why you need to run the tests on a RISC-V board
specifically. It may be that's needed to interact with actual hardware,
it may be emulation is good enough -- meson explicitly supports running
an emulator to test that the binaries work, as Jussi notes.

Perhaps more generally you want something like this:

https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests

> riscv64-unknown-linux-gnu/12042024/sysroot/lib/libm.so.6', needed by
> 'test/common/common-c', missing and no known rule to make it
>
> The path that it is showing is of the x86 compute instance. After checking
> the build. ninja file, it seems that meson stores the absolute path to
> cross compiler and tries to access the libraries (which are not available
> since I moved the project to RISC-V instance and tried to execute tests
> there). Is there a way to produce setup this in such a way that it
> cross-compiles source code for RISC-V and then I can execute the test on an
> actual RISC-V instance?

That's a build dependency, since ninja needs to link to libm.so.6, and
relink if the linker dependencies get updated. Meson isn't designed to
work when moving the build directory to a different filesystem on
different hardware with different dependencies installed.

What you are trying to do is move the build directory wholesale,
including both building and testing infrastructure, in order to use the
testing infrastructure of `meson test` -- and discovering that this
breaks the `ninja` compilation infrastructure, because it can no longer
figure out how to do this.


--
Eli Schwartz