Respect LIBS environment variable

[matoro]

GNU autoconf uses the LIBS environment variable to specify additional libraries to link.. This variable is distinct from LDFLAGS. The latter is for flags that affect the behavior of the linker, while the former is for libraries to link. This means that LDFLAGS is free to be placed before the object files in the command line, while LIBS must be placed after the object files. The manual is very explicit about this in the description for LDFLAGS:

Don’t use this variable to pass library names (-l) to the linker; use LIBS instead.

There is a use-case for this. On some architectures, like riscv, i386, and 32-bit sparc and mips, the GCC __atomic intrinsics are implemented in software via the libatomic library. This means that packages using those intrinsics must link with with -latomic, but only on certain platforms. On such platforms, the user will often need to set LIBS="-latomic" to successfully link. This is easy to do with autotools-based projects, but meson does not know about this environment variable.

[eli-schwartz]

Wasn't there some GCC discussion about adding --push-state --as-needed -latomic --pop-state to the builtin spec on those platforms? This seems like a considerably more robust approach.

[matoro]

Wasn't there some GCC discussion about adding --push-state --as-needed -latomic --pop-state to the builtin spec on those platforms? This seems like a considerably more robust approach.

Perhaps, and I can definitely look into this if you have a link. However this isn't necessarily only the use case - just the particular one that prompted this issue. A change to the gcc specs would take quite a long time before trickling down across the ecosystem. A meson patch would be much faster.

[eli-schwartz]

Found some discussion:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 but mostly https://github.com/riscv-collab/riscv-gcc/issues/12

I'm referring to option 4. It apparently was originally implemented, but later limited to whenever -pthread was passed, leading to the confusing situation where programs that use both threads and atomics worked, but programs that use only atomics did not work.

Also you're suggesting Meson implement a feature request to enable option 5. ;)

[matoro]

Found some discussion:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 but mostly riscv-collab/riscv-gcc#12

I'm referring to option 4. It apparently was originally implemented, but later limited to whenever -pthread was passed, leading to the confusing situation where programs that use both threads and atomics worked, but programs that use only atomics did not work.

Also you're suggesting Meson implement a feature request to enable option 5. ;)

Yes. Here's my justification:

• autotools supports it. I think this is the biggest point in favor. I think cmake might support it with https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_STANDARD_LIBRARIES.html
• adding at the build system layer makes the most sense, as it allows distros to work around it without requiring upstream involvement or support for each individual package (not saying there can't be, but that is a much higher hurdle to clear for large distro repos)
• adding at the gcc level adds a gcc lower bound dependency to projects that wouldn't have one otherwise, and takes significantly longer to filter down to distros

[dcbaker]

We handle a atomics in mesa and it’s a pain. Regardless of what we do with LIBS I think a built in dependency for atomics might be in order

[thesamesam]

See also https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8756.

[eebssk1]

So How do I add addition drop-in libraries to end of meson's linking command? Is there anyway without modifying the build file?

[dcbaker]

@eebssk1 meson setup $builddir -Dc_link_args=... (also works with meson configure), use <lang>_link_args, so cpp_link_args, objc_link_args, etc.

[eebssk1]

@eebssk1 meson setup $builddir -Dc_link_args=... (also works with meson configure), use <lang>_link_args, so cpp_link_args, objc_link_args, etc.

Hi. I tried this. However the flags are added before the actual (start-group objs stop-group) when final exe linking.

I checked the meson config log, the flags indeed appear at the end of the link command though.

[eebssk1]

@eebssk1 meson setup $builddir -Dc_link_args=... (also works with meson configure), use <lang>_link_args, so cpp_link_args, objc_link_args, etc.

Hi. I tried this. However the flags are added before the actual (start-group objs stop-group) when final exe linking.

I checked the meson config log, the flags indeed appear at the end of the link command though.

@dcbaker I think I found the problem here after checking build.ninja. When building a executable, its dependencies reside in $LINK_ARGS instead of $in. I think this is by design. However, passed _link_args come before the dependencies. This behavior is inconsistent between what you told/the config log and the actual link.

update: meson version 1.0.1 from debian bookworm update2: version 1.5.1 from backports still same.

[eebssk1]

@eebssk1 meson setup $builddir -Dc_link_args=... (also works with meson configure), use <lang>_link_args, so cpp_link_args, objc_link_args, etc.

Hi. I tried this. However the flags are added before the actual (start-group objs stop-group) when final exe linking. I checked the meson config log, the flags indeed appear at the end of the link command though.

@dcbaker I think I found the problem here after checking build.ninja. When building a executable, its dependencies reside in $LINK_ARGS instead of $in. I think this is by design. However, passed _link_args come before the dependencies. This behavior is inconsistent between what you told/the config log and the actual link.

For quick and dirty workaround that people may find useful for such situation. I added the flags manually at end of "rule c_LINKER -> command" and the build works as intented.

[dcbaker]

@eebssk1 right, that's because if they're found in the meson.build file Meson knows what they are and handles them accordingly. the c_link_args are just a string list of flags that Meson attaches to the end of the link command, it doesn't know anything about them.

I've been meaning to look at this particular series again, since we do some of this dance in Mesa, but it's kinda a pain to know if we need -latomic