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 riscvarchive/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. ;)

[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.