https://bugzilla.redhat.com/show_bug.cgi?id=2373805 --- Comment #13 from Gerald Cox <gbcox@xxxxxx> --- Here is some analysis provided by openai and gemini. TLDR: libresolv.so.2 Unused Dependency: rpmlint flagged this as an unused direct dependency. Reviewer Analysis: libresolv.so.2 is indeed unused because the necessary network symbols are provided by libc.so.6. Attempted Fix: You tried the netgo build tag to force Go's pure resolver, hoping to eliminate the dependency. Result: The libresolv.so.2 library is still listed in the binary's NEEDED section (meaning it's pulled in by the linker) and ldd -u still reports it as an "Unused direct dependency." Conclusion: This is a persistent quirk of Go's external linking process—the binary requests libresolv.so.2 even when libc satisfies the actual symbol needs. Longer version: You've provided very insightful output from readelf -d! The line you found: 0x0000000000000001 (NEEDED) Shared library: [libresolv.so.2] This is the key piece of information that answers "why beetbrainz is pulling it in." The NEEDED section of a binary's dynamic (ELF) header explicitly lists the shared libraries that the program requires to run. What this means: The binary explicitly declares a need for libresolv.so.2. This entry is written into the executable by the linker (ld) during the build process. When you run beetbrainz, the system's dynamic linker (ld.so) will load libresolv.so.2 because the binary says it needs it. ldd -u correctly reports it as an "Unused direct dependency" because the actual symbols that beetbrainz needs for network operations (like getaddrinfo) are provided by libc.so.6. So, while libc is handling the symbol resolution, the linker has still embedded libresolv.so.2 in the NEEDED list. Why this might happen (the deeper "why"): This scenario typically points to a nuance in how Go's external linker (or the golang-macros if it adds flags) interacts with the system linker. Default Linker Flags from Go: The Go toolchain, when compiling a network-aware application with -linkmode external, might by default add -lresolv to the gcc/ld command line it executes. Even with --as-needed, if the linker is presented with libresolv.so.2 and there's any possible path or internal Go runtime code that could reference a symbol from it (even if libc also provides it), it might choose to list it in NEEDED. Overlapping Functionality: As mentioned, libc has integrated many functions historically found in libresolv. But if libresolv.so.2 contains additional or alternative implementations of related functions, or if the linking order or specific Go runtime behavior causes it to reference libresolv's version of a symbol over libc's, it could get pulled in. Essentially, the binary is "pulling it in" because the NEEDED entry tells the system to load it. The ldd -u output then clarifies that, despite being pulled in, it's not actually used by the application's executed code because its symbol needs are met elsewhere. It's a harmless, albeit slightly inefficient, quirk in this specific Go build context. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2373805 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202373805%23c13 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
