• exp is used in CRollingBloomFilter::CRollingBloomFilter (in our code)
• fcntl64 has a data reference, it's not ever called in the code (objdump -d bitcoin-qt|grep fcntl64@plt shows nothing)

$ objdump -R bitcoin-qt|grep fcntl64                                                            
00000000022b25d0 R_X86_64_64       fcntl64@GLIBC_2.28
$ gdb bitcoin-qt.dbg
(gdb) info symbol 0x00000000022b25d0
aSyscall + 176 in section .data

aSyscall appears to come from the sqlite dependency

• getentropy is used in QRandomGenerator::SystemGenerator::generate (inside qt)
• getrandom is used in one place: arc4_stir at evutil_rand.c:? (libevent dependency)
• log is used in various places throughout the code (mainly for log2_work computation for debug)
• pow is used in many places in our code, also in qt
• renameat is used in QFileSystemEngine::renameFile (inside qt)
• statx is used in three places (QFileSystemMetaData inside qt)

Is there a reference document that explains what the offset is? I found a doc that mentioned it, but my reading of that also came to the original conclusion that you made.

Is there a reference document that explains what the offset is?

I couldn't find anything. But this matches the objdump output, and what the linker itself seems to do, which seems kind of important for a symbol check.

All the other offsets (vn_next, vna_next) are relative to the referring record, so it is at least consistent.

Found it:

vn_aux

The byte offset, from the start of this Elf32_Verneed entry, to the Elf32_Vernaux array of version definitions that are required from the associated file dependency. At least one version dependency must exist. Additional version dependencies can be present, the number being indicated by the vn_cnt value.

Source: Oracle, of all places…

Need more time to reason about the last commit to final ACK.

FWW, the last commit is a continuation of #17538 from 2019, which bumped the minimum glibc to 2.17. See also your comment here you were rightly confused: #17538 (comment)

Maybe it would be better to rewrite the code so that the minimum GLIBC version isn't split over two places?

Maybe it would be better to rewrite the code so that the minimum GLIBC version isn't split over two places?

Okay, pushed a new last commit that does this. Instead of hardcoding a separate table for GLIBC, it optionally allows entries in MAX_VERSIONS to be a per-architecture dictionary. I hope this is clearer.

This unfortunately brings to light some symbols that have been introduced since and weren't caught (from a gitian compile of master):

On master, with applied #22281, #22287 and this PR:

Checking glibc back compat...
bitcoind: symbol getrandom from unsupported version GLIBC_2.25
bitcoind: failed IMPORTED_SYMBOLS
bitcoin-cli: symbol getrandom from unsupported version GLIBC_2.25
bitcoin-cli: failed IMPORTED_SYMBOLS
test/test_bitcoin: symbol getrandom from unsupported version GLIBC_2.25
test/test_bitcoin: failed IMPORTED_SYMBOLS
qt/bitcoin-qt: symbol statx from unsupported version GLIBC_2.28
qt/bitcoin-qt: symbol getrandom from unsupported version GLIBC_2.25
qt/bitcoin-qt: symbol renameat2 from unsupported version GLIBC_2.28
qt/bitcoin-qt: symbol getentropy from unsupported version GLIBC_2.25
qt/bitcoin-qt: failed IMPORTED_SYMBOLS

For statx and renameat2 I opened a dedicated #22280.

@laanwj

* `getentropy` is used in `QRandomGenerator::SystemGenerator::generate` (inside qt)

* `getrandom` is used in one place: `arc4_stir at evutil_rand.c:?`  (libevent dependency)

Removed in #22318.

@laanwj

• renameat is used in QFileSystemEngine::renameFile (inside qt)

• statx is used in three places (QFileSystemMetaData inside qt)

Removed in #22321.

With #22281, #22287/#22305, #22318 and #22321 combined the symbol-check.py passes successfully.