Bug: C integration tests fail at runtime under GCC/GNU ld: `undefined symbol: ring_core_*` in cdylib

[MocioF]

This is an issue and not a support question which should be asked at https://forum.greenbone.net/?

• This is an issue and not a support question

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Summary

When building gvm-auth-lib with GCC + GNU ld (binutils) as the toolchain, the C integration tests (test-jwt, test-oauth2, test-version) fail at runtime with a dynamic symbol lookup error. The same source built with Clang + LLD passes.

The produced libgvm_auth.so cdylib contains unresolved references to its own statically-linked crypto backend symbols (ring_core_*, and equivalently aws_lc_*). These symbols are present in the static archives that are linked into the cdylib, but they are not retained/resolvable in the resulting shared object when the link is performed by GNU ld. Under LLD they are retained, which is why the discrepancy is toolchain-dependent.

I have found this issue while writing an ebuild (attached) for gentoo.

gvm-auth-lib-0.2.2.ebuild.txt (the .txt is just because files ending in .ebuild are not allowed as attachments)

gvm-auth-lib-0.2.2-remove-unkorking-tests.patch

Expected Behavior

No response

Steps To Reproduce

No response

Operating System

OS: Gentoo Linux

Version

• Toolchain (fails): GCC 15.2.1, GNU ld / binutils 2.46
• Toolchain (works): Clang 21.1.8 with LLD
• Rust: 1.88+
• Relevant crates in the dependency graph: ring 0.17.14, aws-lc-sys 0.40.0 / aws-lc-rs, pulled in transitively (e.g. via jsonwebtoken)

Anything else?

Symptom

The C tests build and link successfully, then fail when executed:

test-jwt: symbol lookup error: .../target/release/libgvm_auth.so: undefined symbol: ring_core_0_17_14__LIMB_is_zero
test-oauth2: symbol lookup error: .../target/release/libgvm_auth.so: undefined symbol: ring_core_0_17_14__LIMB_is_zero
test-version: symbol lookup error: .../target/release/libgvm_auth.so: undefined symbol: ring_core_0_17_14__LIMB_is_zero

Note the failing object is the freshly built target/release/libgvm_auth.so itself — the test harness is loading the correct library; the library's own internal symbols are not resolvable at load time.

The Rust unit/integration tests (cargo test) all pass under the same GCC toolchain; only the C integration tests linking the cdylib by path are affected.

[bjoernricks]

Should be fixed now with the latest release. Could you verify that?

[MocioF]

I succeeded in building 0.2.3 with GCC.
About: 763b136
in my ebuild I added -Wl,--allow-shlib-undefined, that now it is unnecessary. Thanks to solve this upstream.
This commit 9220b98 avoid me to add soname after build, thanks again.

However, to build with GCC, in my ebuild I adedd filter-flags '-flto* in configure phase to disable LTO.
I think that the problem is that Rust extensions are incompatible with C/C++ LTO compiler and while
the cargo.eclass filters -flto* out of CFLAGS before invoking cargo
cmake.eclass's cmake_src_compile/cmake_src_configure (used to compile aws-lc-sys/ring) does not filter it.