glibc-devel-2.28 libc_nonshared.a relocation issues

[Brendan Batliner]

Hi all,

We encountered a rather specific and curious issue upgrading our C++ builds from running on CentOS 7 to running on CentOS 8. ld complains about linking a symbol from glibc:

/.../bin/ld: /usr/lib64/libc_nonshared.a(atexit.oS): in function `atexit':
(.text+0x7): relocation truncated to fit: R_X86_64_PC32 against symbol `__dso_handle' defined in .data section in /.../gcc/stage-8.2.0/bin/lib/gcc/x86_64-pc-linux-gnu/8.2.0/crtbegin.o

An objdump confirms the 32-bit relocations:

$ objdump -r /usr/lib64/libc_nonshared.a | grep __dso_handle
0000000000000007 R_X86_64_PC32     __dso_handle-0x0000000000000004
0000000000000007 R_X86_64_PC32     __dso_handle-0x0000000000000004
0000000000000007 R_X86_64_PC32     __dso_handle-0x0000000000000004

The package providing this archive is glibc-devel-2.28-101.el8.x86_64. I've confirmed the older version glibc-devel-2.28-18.el8.x86_64 also has 32-bit relocations for these symbols.

Notably, the libc_nonshared.a from glibc-devel-2.17-307.el7.1.x86_64 (the latest version distributed for CentOS 7) has 64-bit relocations:

$ objdump -r /usr/lib64/libc_nonshared.a | grep __dso_handle
0000000000000003 R_X86_64_GOTPCREL  __dso_handle-0x0000000000000004
0000000000000003 R_X86_64_GOTPCREL  __dso_handle-0x0000000000000004

This is a problem for our builds because libc_nonshared.a is statically linked, and our large binaries require the use of mcmodel=large. The 32-bit relocations present in libc_nonshared.a from glibc-devel-2.28 are not compatible with our builds.

What is the correct workaround for this issue? How should we proceed? Thank you for any advice.

Thanks,
Brendan Batliner