* glibc-devel-2.28 libc_nonshared.a relocation issues
@ 2020-08-13 18:23 Brendan Batliner
2020-08-13 18:45 ` Florian Weimer
0 siblings, 1 reply; 3+ messages in thread
From: Brendan Batliner @ 2020-08-13 18:23 UTC (permalink / raw)
To: libc-help
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: glibc-devel-2.28 libc_nonshared.a relocation issues
2020-08-13 18:23 glibc-devel-2.28 libc_nonshared.a relocation issues Brendan Batliner
@ 2020-08-13 18:45 ` Florian Weimer
2020-08-14 15:22 ` Brendan Batliner
0 siblings, 1 reply; 3+ messages in thread
From: Florian Weimer @ 2020-08-13 18:45 UTC (permalink / raw)
To: Brendan Batliner; +Cc: libc-help
* Brendan Batliner:
> 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.
I do not think there is a workaround. This seems to be a regression
introduced by this commit:
commit 825adeeed1e95990fd1efb70d9ac3eb7f1ea802a
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Sep 26 16:53:25 2017 -0700
Mark __dso_handle as hidden [BZ #18822]
Since __dso_handle is always defined by either crtbegin.o from GCC or
dso_handle.c, it should be marked as hidden and be passed directly.
Would you please file a bug here?
<https://sourceware.org/bugzilla/enter_bug.cgi?product=glibc&component=libc>
Maybe the link editor could be a bit smarter about this, but that's a
different conversation.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: glibc-devel-2.28 libc_nonshared.a relocation issues
2020-08-13 18:45 ` Florian Weimer
@ 2020-08-14 15:22 ` Brendan Batliner
0 siblings, 0 replies; 3+ messages in thread
From: Brendan Batliner @ 2020-08-14 15:22 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-help
Thanks Florian. Bug filed here:
https://sourceware.org/bugzilla/show_bug.cgi?id=26386
________________________________
From: Florian Weimer <fw@deneb.enyo.de>
Sent: Thursday, August 13, 2020 1:45 PM
To: Brendan Batliner <bbatliner@ocient.com>
Cc: libc-help@sourceware.org <libc-help@sourceware.org>
Subject: Re: glibc-devel-2.28 libc_nonshared.a relocation issues
* Brendan Batliner:
> 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.
I do not think there is a workaround. This seems to be a regression
introduced by this commit:
commit 825adeeed1e95990fd1efb70d9ac3eb7f1ea802a
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Sep 26 16:53:25 2017 -0700
Mark __dso_handle as hidden [BZ #18822]
Since __dso_handle is always defined by either crtbegin.o from GCC or
dso_handle.c, it should be marked as hidden and be passed directly.
Would you please file a bug here?
<https://sourceware.org/bugzilla/enter_bug.cgi?product=glibc&component=libc>
Maybe the link editor could be a bit smarter about this, but that's a
different conversation.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-08-14 15:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-13 18:23 glibc-devel-2.28 libc_nonshared.a relocation issues Brendan Batliner
2020-08-13 18:45 ` Florian Weimer
2020-08-14 15:22 ` Brendan Batliner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).