`dependency('atomic')` can return false results on Fedora

[meator]

Describe the bug
dependency('atomic') is marked as found even though the /usr/lib64/libatomic.so.1.2.0 library doesn't exist.

This is most likely caused by my build environment missing the appropriate package (I think it's libatomic or something, I'm not a Fedora guy). But that is no excuse for dependency('atomic') to return a found dependency.

Relevant error messages
(These come from the Dockerfile below)

Run-time dependency atomic found: YES
Checking if "Check if libatomic is required" with dependency atomic links: NO

meson.build:35:2: ERROR: Problem encountered: Host machine cannot handle atomics!

Command line: `c++ /build/meson-private/tmpe47p63sa/testfile.cpp -o /build/meson-private/tmpe47p63sa/output.obj -c -D_FILE_OFFSET_BITS=64 -O0 -fpermissive --print-search-dirs` -> 0
stdout:
install: /usr/lib/gcc/x86_64-redhat-linux/15/
programs: =/usr/libexec/gcc/x86_64-redhat-linux/15/:/usr/libexec/gcc/x86_64-redhat-linux/15/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/15/:/usr/lib/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/15/../../../../x86_64-redhat-linux/bin/x86_64-redhat-linux/15/:/usr/lib/gcc/x86_64-redhat-linux/15/../../../../x86_64-redhat-linux/bin/
libraries: =/usr/lib/gcc/x86_64-redhat-linux/15/:/usr/lib/gcc/x86_64-redhat-linux/15/../../../../x86_64-redhat-linux/lib/x86_64-redhat-linux/15/:/usr/lib/gcc/x86_64-redhat-linux/15/../../../../x86_64-redhat-linux/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/15/../../../x86_64-redhat-linux/15/:/usr/lib/gcc/x86_64-redhat-linux/15/../../../../lib64/:/lib/x86_64-redhat-linux/15/:/lib/../lib64/:/usr/lib/x86_64-redhat-linux/15/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/15/../../../../x86_64-redhat-linux/lib/:/usr/lib/gcc/x86_64-redhat-linux/15/../../../:/lib/:/usr/lib/
-----------
Run-time dependency atomic found: YES
Running compile:
Working directory:  /build/meson-private/tmpdd0hyh67
Code:

#include <atomic>
#include <cstdint>
int main() {
    volatile std::atomic<std::uint64_t> testvar;
    // The line below will lead to
    // undefined reference to `__atomic_fetch_add_8'
    // on armv6l to give an example.
    volatile auto unused = testvar.fetch_add(0);
}

-----------
Command line: `c++ /build/meson-private/tmpdd0hyh67/testfile.cpp -o /build/meson-private/tmpdd0hyh67/output.exe -D_FILE_OFFSET_BITS=64 -O0 -fpermissive /usr/lib/gcc/x86_64-redhat-linux/15/libatomic.so` -> 1
stderr:
/usr/sbin/ld: cannot find /usr/lib64/libatomic.so.1.2.0: No such file or directory
collect2: error: ld returned 1 exit status
-----------
Checking if "Check if libatomic is required" with dependency atomic links: NO

meson.build:35:2: ERROR: Problem encountered: Host machine cannot handle atomics!

To Reproduce

FROM fedora:42
RUN <<EOF
set -eu
dnf install -y gcc gcc-g++ meson
cat > meson.build <<"END"
project(
  'repro',
  'c', 'cpp',
)

if meson.version().version_compare('>=1.7.0')
  atomic_dep = dependency(
    'atomic',
    required: false,
  )
else
  atomic_dep = meson.get_compiler('cpp').find_library(
    'atomic',
    required: false,
  )
endif

# Make reasonable effort (volatile) to prevent the compiler from optimizing the atomic away without using tested
# functionality.
if not meson.get_compiler('cpp').links(
  '''
#include <atomic>
#include <cstdint>
int main() {
    volatile std::atomic<std::uint64_t> testvar;
    // The line below will lead to
    // undefined reference to `__atomic_fetch_add_8'
    // on armv6l to give an example.
    volatile auto unused = testvar.fetch_add(0);
}
  ''',
  name: 'Check if libatomic is required',
  dependencies: atomic_dep,
)
  error('Host machine cannot handle atomics!')
endif
END
if ! meson setup build; then
  cat build/meson-logs/meson-log.txt >&2
  exit 1
fi
EOF

Expected behavior
The dependency should fail to resolve (in the sample code above it's set as required: false, so it should resolve to a not-found dependency).

system parameters

• native build
• Fedora latest and rawhide (42, 43)
• I think Meson is using Python version 3.13.7, but I don't think that's hugely relevant here.
• tested Meson versions 1.7.2 (from Fedora package used above) and 0f5cd5f (current HEAD)
• Ninja 1.12.1

[RobotLeopard86]

Using meson.get_compiler('cpp').find_library('atomic') works on my Fedora (42) in all Meson versions I have used thus far, so maybe it's a dependency specific thing? In the meantime my approach should work as a substitute for whatever you're doing.

[meator]

@RobotLeopard86 It is most certainly a dependency() specific thing.

The approach you're describing isn't portable. Additional checking has to be done. The purpose of dependency('atomic') is to simplify the process. But you're right, the "long winded" approach (which had to be used before the special atomic dependency got introduced in Meson) is still functional, even on Fedora.

The problem is that a found dependency gets returned for a library which is not installed.

It is acceptable (but unfortunate) when a dependency isn't found when it's available. It is unacceptable to have a found dependency when the dependency isn't available.

[RobotLeopard86]

Obviously the issue with dependency needs to be resolved. I was just suggesting what you could do in the meantime since it hasn't been fixed yet.

And what do you mean by find_library not being portable and needing additional checks? If it's a platform thing just do a conditional in the required kwarg. Does it not find it on some systems?

I'm not familiar with the history of the atomic dependency stuff; I only really started using Meson around 1.2.0 I think, so if there's additional context here, I wouldn't know it.

[eli-schwartz]

The issue is that atomic is a bit like libc.so.6, in that simply using the abstract concept of programming languages and machine code, and compilers for the compilation of the former into the latter, is liable at any time to generate a link-time requirement to providers of "a library that provides support for atomics". You don't even need to use a header -- atomics can be manually used in your code using pure keywords.

However, and this is a truly appalling "however", there is no way -- none at all -- to actually know a series of important facts:

• does your toolchain distribute atomic as part of libc or inlined compiler built-ins
• does your toolchain require a distinct atomics support library
• does your toolchain provide some things in libc / inlined compiler built-ins and some things via a separate support library
• is there a code snippet that can reliably detect the answer to the second question, without giving erroneous results for the third question

To this we may add a fifth question:

• does your toolchain qualify as either 2 or 3, and the atomic library does exist on disk -- but as a broken symlink or linker script, indicating that the actual installed package is "bricked" and in an inconsistent state

I am alarmed that question 5 is possible to encounter, but it is true to my great dismay. Fedora's GCC package provides the development headers and development libatomic.so, but doesn't depend on the separated runtime library. This is a clear and evident fedora bug.

[eli-schwartz]

The problem is that a found dependency gets returned for a library which is not installed.

Unfortunately the only reliable way to implement this is to replace dependency('atomic') with

def get_atomic_dependency():
    print('warning: this question is unknowable and cannot be answered')
    return False

    print('BUG: unreachable code')
    return '-latomic'

There is NO way to guarantee you have found code which actually correctly raises an error if atomics are missing but needed.

I'm of course happy to accept and merge proposals for code that has better chances of triggering a link-time requirement for a standalone atomics support library. I just don't believe it's possible to do it "perfectly".

It is acceptable (but unfortunate) when a dependency isn't found when it's available. It is unacceptable to have a found dependency when the dependency isn't available.

But strictly speaking, it was available. Some atomics do work, apparently, even without -latomic. Just not all atomics.

I'm afraid I hold the exact opposite opinion to you. It's unacceptable if meson forbids users from building valid and working code because meson erroneously believes it won't work. It's unfortunate, but not the end of the world, when meson cannot determine the answer to the question, and allows you to attempt to compile the project only to discover at build time (rather than at setup time) that the project cannot be built.

It is ideal for meson to safely and correctly detect errors as fast as possible -- i.e. during setup -- and getting better at that is an important and valuable goal for which we are happy to receive suggestions. And obviously meson must not intentionally ignore known fatal errors and let you try to build anyway.

[bonzini]

I agree that there is a Fedora bug, but atomics do mostly work without libatomic. In fact, at least for code where I use atomics, needing libatomic would be a bug and, if I were interested in porting to such platforms, I would use a mutex instead so that the code's performance and ordering characteristics are uniform.

Honestly I would just deprecate or even remove dependency('atomic'). libatomic is problematic to rely on and Meson is opinionated on stuff that is much less problematic.

[eli-schwartz]

Honestly I would just deprecate or even remove dependency('atomic'). libatomic is problematic to rely on and Meson is opinionated on stuff that is much less problematic.

Generally that doesn't mean meson tells users "you must not use this particular part of the language standard". Or indeed, "you must not use $DEPENDENCY" for any given value of a dependency. Providing a uniform way to detect the availability of a system interface is a valuable goal that doesn't require meson to make judgment calls about whether someone is "kinda lame at programming, actually" for wanting to use said system interface.

The main reason libatomic is problematic to rely upon is because gcc's default specs should automatically generate -Wl,--push-state,--as-needed -latomic -Wl,--pop-state on installations that ship with a libatomic.so, such that users don't need to manually request a library to get standard functionality.

[bonzini]

Generally that doesn't mean meson tells users "you must not use this particular part of the language standard".

Yes, I agree. But it's a fairly niche part.

gcc's default specs should automatically generate -Wl,--push-state,--as-needed -latomic -Wl,--pop-state on installations that ship with a libatomic.so

That would work if there was also a way to turn libatomic references into a compile-time error—or, even better, to allow libatomic on an opt-in basis.

[RobotLeopard86]

I'm by no means an expert here, but I was going back through this thread and I had an idea for how this could be resolved.

Like @eli-schwartz said, there is no one code snippet to reliably detect what is needed with regard to libatomic... so why not take a different approach?

This isn't a binary question, so why would we try to solve it using a binary approach of "it compiles" or "it doesn't compile"?

My idea is (and this is purely theoretical, not sure what the code for this would look like) to make a code snippet that should in theory render libatomic necessary if it is separate in any way and add something like those GCC flags. Then, since libatomic is typically distributed as a shared lib, we could inspect the resulting binary (assuming it compiles) with nm (or similar tools) to see if we actually got a libatomic dependency. Before this we could also try to find libatomic ourselves to inspect the file type; if it's static then we would use nm to find known symbols present in both libatomic and the test binary, and if libatomic is anything else we say that the dependency was not found.

Sorry if this seems like an incoherent jumble of nonsense, I'm writing this on my phone as I had a brainwave. Happy to (try to) help clarify any specific points.

[eli-schwartz]

Then, since libatomic is typically distributed as a shared lib, we could inspect the resulting binary (assuming it compiles) with nm (or similar tools) to see if we actually got a libatomic dependency.

That's not a problem, if libatomic exists and is a shared library we can simply link to it always, whether it is needed or not. We don't need to inspect the binary for anything.

-D b_asneeded=true is relevant here. Adding a dependency that exists, but isn't "actually needed" is harmless because the project still builds and the unneeded runtime dependencies are stripped out once the linker realizes they aren't used.

We just need "a code snippet that should in theory render libatomic necessary if it is separate in any way" so we can detect the difference between libatomic being "not separate" and "needed, but the libatomic package hasn't been installed".

[RobotLeopard86]

Maybe we don't need an extra-special code snippet. Not sure if this would work, but would it be possible to make a code snippet, compile and link with libatomic always (if that fails to compile then libatomic probably wasn't found), and then use nm to inspect the resulting binary. If libatomic is needed, then some known symbols should remain in the file. If not, then they should be stripped out.

[eli-schwartz]

The extra-special code snippet is the thing that causes nm to show that known symbols are being used.

All roads lead back to needing an extra-special code snippet.

[RobotLeopard86]

Well, maybe we don't use just one snippet. As you stated above, the questions we need to answer are:

• does your toolchain distribute atomic as part of libc or inlined compiler built-ins
• does your toolchain require a distinct atomics support library
• does your toolchain provide some things in libc / inlined compiler built-ins and some things via a separate support library
• does your toolchain qualify as either 2 or 3, and the atomic library does exist on disk -- but as a broken symlink or linker script, indicating that the actual installed package is "bricked" and in an inconsistent state

Firstly, we search for libatomic ourselves on disk. If it doesn't, then it's not necessary and we know it's just builtins or missing. If it does, and it's a real library, then we'll probably need it and can return it. If it does and it's something weird and broken, we error.

Now we know the following:
a) Is there a separate libatomic library?
b) If so, is it valid?

If there is no separate libatomic library, we compile-check a snippet (probably in C, not C++) to ensure that atomics work using builtins/libc. If that fails, then we know libatomic is not installed and needs to be.

If there is a separate libatomic library, we first use ldd or otool or friends to determine if libc is linked to libatomic. If it is, we do the same check as above, because libatomic should be pulled in. If we get a compile failure, then something is wrong for some unrelated reason. If we get a linker failure then we should try again with libatomic explicitly linked. If that fails then we know something's broken and error.

If libatomic is not pulled in by libc, then we do the test that I just mentioned with libatomic linked explicitly. If that fails, error.

I don't know if this strategy would account for all the edge cases but I'd imagine it would handle most common scenarios.

[meator]

In the mean time, my original snippet (which is included in the issue description and some other places too) can be modified to still make it a configure-time error but print a better error message:

if meson.version().version_compare('>=1.7.0')
  atomic_dep = dependency(
    'atomic',
    required: false,
  )
else
  atomic_dep = meson.get_compiler('cpp').find_library(
    'atomic',
    required: false,
  )
endif

# Make reasonable effort (volatile) to prevent the compiler from optimizing the
# atomic away without using tested functionality.
if not meson.get_compiler('cpp').links(
  '''
#include <atomic>
#include <cstdint>
int main() {
    volatile std::atomic<std::uint64_t> testvar;
    // The line below will lead to
    // undefined reference to `__atomic_fetch_add_8'
    // on armv6l to give an example.
    volatile auto unused = testvar.fetch_add(0);
}
  ''',
  name: 'Check if libatomic is required',
  dependencies: atomic_dep,
)
  error(
    'Host machine either cannot handle atomics or you are missing a',
    'libatomic dependency (Fedora is prone to this)!'
  )
endif

I hoped that the links() check above was only necessary for the old approach, but that doesn't appear to be the case. By the way, I need libatomic because of the following things in protobuf:

Linker errors

/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/protobuf-25.2/libprotobuf.a.p/src_google_protobuf_arena.cc.o: in function `google::protobuf::internal::ThreadSafeArena::ThreadSafeArena()':
arena.cc:(.text+0x1dec): undefined reference to `__atomic_fetch_add_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/protobuf-25.2/libprotobuf.a.p/src_google_protobuf_arena.cc.o: in function `google::protobuf::internal::ThreadSafeArena::ThreadSafeArena(char*, unsigned int)':
arena.cc:(.text+0x1fbc): undefined reference to `__atomic_fetch_add_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/protobuf-25.2/libprotobuf.a.p/src_google_protobuf_arena.cc.o: in function `google::protobuf::internal::ThreadSafeArena::GetNextLifeCycleId()':
arena.cc:(.text+0x2328): undefined reference to `__atomic_fetch_add_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/protobuf-25.2/libprotobuf.a.p/src_google_protobuf_arena.cc.o: in function `google::protobuf::internal::ThreadSafeArena::Init()':
arena.cc:(.text+0x298c): undefined reference to `__atomic_fetch_add_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/protobuf-25.2/libprotobuf.a.p/src_google_protobuf_arena.cc.o: in function `google::protobuf::internal::ThreadSafeArena::Reset()':
arena.cc:(.text+0x2ec4): undefined reference to `__atomic_fetch_add_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/protobuf-25.2/libprotobuf.a.p/src_google_protobuf_arena.cc.o:arena.cc:(.text+0x44ec): more undefined references to `__atomic_fetch_add_8' follow
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/protobuf-25.2/libprotobuf.a.p/src_google_protobuf_text_format.cc.o: in function `google::protobuf::internal::GetRedactedFieldCount()':
text_format.cc:(.text+0x1c80): undefined reference to `__atomic_load_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/abseil-cpp-20240722.0/libabsl_strings.a.p/absl_strings_internal_cordz_info.cc.o: in function `absl::lts_20240722::cord_internal::CordzInfo::CordzInfo(absl::lts_20240722::cord_internal::CordRep*, absl::lts_20240722::cord_internal::CordzInfo const*, absl::lts_20240722::cord_internal::CordzUpdateTracker::MethodIdentifier, long long)':
cordz_info.cc:(.text+0x7c0): undefined reference to `__atomic_load_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: cordz_info.cc:(.text+0x7d8): undefined reference to `__atomic_store_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: cordz_info.cc:(.text+0x808): undefined reference to `__atomic_load_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: cordz_info.cc:(.text+0x824): undefined reference to `__atomic_load_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: cordz_info.cc:(.text+0x83c): undefined reference to `__atomic_store_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/abseil-cpp-20240722.0/libabsl_strings.a.p/absl_strings_internal_cordz_info.cc.o: in function `absl::lts_20240722::cord_internal::CordzInfo::Lock(absl::lts_20240722::cord_internal::CordzUpdateTracker::MethodIdentifier)':
cordz_info.cc:(.text+0x10e4): undefined reference to `__atomic_load_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: cordz_info.cc:(.text+0x10fc): undefined reference to `__atomic_store_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/abseil-cpp-20240722.0/libabsl_strings.a.p/absl_strings_internal_cordz_info.cc.o: in function `absl::lts_20240722::cord_internal::CordzInfo::GetCordzStatistics() const':
cordz_info.cc:(.text+0x11d0): undefined reference to `__atomic_load_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: cordz_info.cc:(.text+0x11e8): undefined reference to `__atomic_store_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/abseil-cpp-20240722.0/libabsl_log.a.p/absl_log_internal_conditions.cc.o: in function `absl::lts_20240722::log_internal::LogEveryNSecState::ShouldLog(double)':
conditions.cc:(.text+0xb4): undefined reference to `__atomic_load_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: conditions.cc:(.text+0x124): undefined reference to `__atomic_compare_exchange_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: subprojects/abseil-cpp-20240722.0/libabsl_base.a.p/absl_base_internal_spinlock_wait.cc.o: in function `absl::lts_20240722::base_internal::SpinLockSuggestedDelayNS(int)':
spinlock_wait.cc:(.text+0x164): undefined reference to `__atomic_load_8'
/usr/local/bin/../lib/gcc/arm-linux-musleabi/14.2.0/../../../../arm-linux-musleabi/bin/ld: spinlock_wait.cc:(.text+0x194): undefined reference to `__atomic_store_8'