How to disable the -rpath options in the linker command?

[ilg-ul]

I finally managed to pass the first link of my embedded project using meson, which is good, since I was not sure it is possible. :-)

However, I noticed that the linker command included two rpath related options:

 -rpath $ORIGIN/ -rpath-link /Users/ilg/My Files/WKS Projects/micro-os-plus.github/xPacks/micro-test-plus-xpack.git/build/qemu-mps2-an386-meson-debug/meson-out

I know that rpath is a great mechanism when building Linux binaries, but in the context of bare-metal embedded applications, shared libraries are not used, applications are flashed to the MCUs and in general rpath makes no sense.

I searched for mentions of rpath in the web pages, but I did not identify many options to control when it is used.

Is there any option, preferably at toolchain level, to disable the use of rpath?

[eli-schwartz]

Meson automatically detects whether rpath is needed using the following conditions:

• manually specified build_rpath or install_rpath as documented on the website, if you manually specify these you are saying you absolutely want them so simply do not do this for bare-metal embedded applications
• in the mesonbuild.backend.backends module, there is a determine_rpath_dirs class method for the backend generator. It adds autodetected rpath directories based on the logic "this is needed to run the program from the build directory" in the event that e.g. some executable has linked to a built library in the build tree. Those are removed at install time, though.

So, this should not be happening if you don't use shared libraries...

[ilg-ul]

manually specified build_rpath or install_rpath

I did not use them, and I explicitly used static_library(), so I don't think I did anything that asks for rpath.

this should not be happening if you don't use shared libraries...

Then either I must add some extra definition to prevent meson doing this, or we might face a small bug, since... it happens :-(

The autodetect logic should not even fire at all, since the arm-none-eabi binaries cannot be executed on my build machine (an Intel macOS), or on any other build machine, the code is specific to Cortex-M devices.

Any suggestion how can we diagnose it?

[eli-schwartz]

The autodetect logic should not even fire at all, since the arm-none-eabi binaries cannot be executed on my build machine (an Intel macOS), or on any other build machine, the code is specific to Cortex-M devices.

It's pretty common to do this sort of thing using qemu-user emulation, so Meson cannot just disable this whenever a cross build is used.

Any suggestion how can we diagnose it?

I dunno... what meson command line did you use to configure? Do you have a sample project to reproduce the issue?

[ilg-ul]

It's pretty common to do this sort of thing using qemu-user emulation,

It is common with a Linux cross compiler, not with arm-none-eabi. It can generate shared libraries too, but I don't know of any embedded framework able to load them.

so Meson cannot just disable this whenever a cross build is used.

Ah, sure, I'm not suggesting this, I'm only trying to fix bare-metal cross builds.

what meson command line did you use to configure?

meson setup --backend ninja --buildtype debug -D platform-name=qemu-mps2-an386 --cross xpacks/micro-os-plus-build-helper/meson/toolchains/arm-none-eabi-gcc.ini --cross tests/platform-qemu-mps2-an386/meson/cross.ini build/qemu-mps2-an386-meson-debug tests

Do you have a sample project to reproduce the issue?

Sure, I'll update the GitHub projects and you'll be able to run the builds on any machine. It'll take me 1-2 more days to fix the small remaining details, I'll let you know when ready.

[ilg-ul]

You can take a look at this run:

• https://github.com/micro-os-plus/diag-trace-xpack/runs/5172562807

Open the qemu-mps2-an386-meson test, and go to line 10621032, you will see the -rpath $ORIGIN/ -rpath-link ... options present in a cross build with arm-none-eabi-gcc, where the RPATH setting makes little sense.

[eli-schwartz]

I don't see anything on line 1062 about rpath. However, the sample project does give me an idea of what is causing it.

[ilg-ul]

Oops, sorry, it is line 1032, a verbose link.

[ilg-ul]

the sample project does give me an idea of what is causing it.

Did I do something wrong?

[eli-schwartz]

Yeah, I see it now.

[eli-schwartz]

Based on your sample project, I believe I understand the problem. In https://github.com/micro-os-plus/diag-trace-xpack/blob/xpack/tests/platform-qemu-mps2-an386/meson/cross.ini you specify:

[built-in options]
# ...
layout = 'flat' # 'mirror'

This will emit a warning on current versions of Meson:

WARNING: -Dlayout=flat is unsupported and probably broken. It was a failed experiment at making Windows build artifacts runnable while uninstalled, due to PATH considerations, but was untested by CI and anyways breaks reasonable use of conflicting targets in different subdirs. Please consider using meson devenv instead. See #9243 for details.

The official recommendation about this option is "it is broken. Do not use it. Don't expect bugs to be fixed in it".

May I ask why you wanted to use layout=flat?

[ilg-ul]

May I ask why you wanted to use layout=flat?

I had issues with very long paths on Windows, and I hoped that a flat layout will shorten the paths.

Where is the warning and the recommendation?

[ilg-ul]

I checked the documentation page for layout=flat (https://mesonbuild.com/Builtin-options.html#core-options) and it does not mention any restrictions.