Linking step refers to the incorrect paths when dual booting.

[gagero]

I dual boot Guix and Fedora. Compiling on Guix, Meson tries to link shared dependencies using Fedora's .so (in this case /usr/lib64/libreadline.so and vice versa (/gnu/store/dl3665ynrp41ynyw2ay5kfqix93myj5d-readline-8.1.2/lib/libreadline.so).

meson.build:

project(
  'example',
  'cpp',
)

readline_dep = dependency('readline')

executable(
  'simpledb',
	'src/main.cpp',
  dependencies: [
    readline_dep
  ]
)

Expected behavior
Meson uses the correct library paths.

Native build
Guix commit 4c56d0cccdc44e12484b26332715f54768738c5f/Fedora 41
Python 3.13.0 on Fedora, 3.10.7 on Guix
Meson 1.5.1 on both Fedora and Guix
ninja 1.12.1 on Fedora, 1.11.1 on Guix

[eli-schwartz]

This report doesn't actually explain what the issue is.

[gagero]

Guix is similar to NixOS, it keeps every package in it's own subdirectory under /gnu/store/. For example, the path to libreadline.so on my system is /gnu/store/dl3665ynrp41ynyw2ay5kfqix93myj5d-readline-8.1.2/lib/libreadline.so but the exact subdirectory would change with a different version of readline. Then it populates a profile directory, which contains symlinks to everything in the package directories and then sets LIBRARY_PATH to this directory. The problem is that on Guix, Meson searches the /usr/lib64/ directory for shared objects, whereas on Fedora, it searches the aforementioned Guix profile directory for shared objects.

[eli-schwartz]

Are you saying that the LIBRARY_PATH produced by Guix is being sourced as an environment variable on your Fedora system?

And that your Guix compiler is configured to search in /usr/lib64?

[gagero]

Yes, even though LIBRARY_PATH's value is empty on Fedora.

[eli-schwartz]

Which one is it?

• is LIBRARY_PATH defined by Guix being sourced as an environment variable on Fedora
• is LIBRARY_PATH empty on Fedora

[eli-schwartz]

Maybe you could share logs of running meson and getting bad results, so we can better visualize the problem you're having?

[gagero]

It's both. LIBRARY_PATH is empty on Fedora and Meson prints

[2/2] Linking target simpledb
FAILED: simpledb 
c++  -o simpledb simpledb.p/src_main.cpp.o -Wl,--as-needed -Wl,--no-undefined -Wl,-rpath,/gnu/store/dl3665ynrp41ynyw2ay5kfqix93myj5d-readline-8.1.2/lib -Wl,-rpath-link,/gnu/store/dl3665ynrp41ynyw2ay5kfqix93myj5d-readline-8.1.2/lib /gnu/store/dl3665ynrp41ynyw2ay5kfqix93myj5d-readline-8.1.2/lib/libreadline.so
/usr/bin/ld: cannot find /gnu/store/dl3665ynrp41ynyw2ay5kfqix93myj5d-readline-8.1.2/lib/libreadline.so: No such file or directory
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

[eli-schwartz]

Please post complete logs, starting with meson setup.

[gagero]

Settiing up the project again with --wipe fixed it but here's the old meson-log.txt, although it doesn't seem to contain the error: https://pastebin.com/5ypyAwVj.

[dnicolodi]

I suspect that what is happening is that the same build directory is used to build the project on two different systems. Meson does not have a way to detect that the world changed under his feet and thus happily tries to compile the project on one system with the project configuration computed on the other. I think that the easy answer is: do not do that. Sharing the same building directory between different systems is not supported.

[gagero]

Thank you, using a different build directory per system worked.