diff options
author | Siddhesh Poyarekar <siddhesh@sourceware.org> | 2021-03-30 14:58:37 +0530 |
---|---|---|
committer | Siddhesh Poyarekar <siddhesh@sourceware.org> | 2021-03-30 14:58:37 +0530 |
commit | 4898d9712bbd85e6fb576442f578d6f3c3e35898 (patch) | |
tree | 6d16bd2f14eee317f5125f880343fb1a4b511a0e /libio | |
parent | abadbef5c89f33bfc084cb00da2345be63c3a0c8 (diff) | |
download | glibc-4898d9712bbd85e6fb576442f578d6f3c3e35898.zip glibc-4898d9712bbd85e6fb576442f578d6f3c3e35898.tar.gz glibc-4898d9712bbd85e6fb576442f578d6f3c3e35898.tar.bz2 |
Avoid adding duplicated symbols into static libraries
Some math functions (such as __isnan*) are built into both libm and
libc because they are needed in libc. The symbol gets exported from
libc.so and not libm.so, because of which dynamic linking works fine;
the symbols are always resolved from libc.so and libm.so uses its
internal copy of the same function if needed.
When linking statically though, the libm variants get used throughout
because the symbols are exported in both archives and libm.a is
searched first.
This patch removes these duplicate objects from the libm.a archive so
that programs always link to libc in both, the static and dynamic
case. The difference this will cause is that libm uses of these
functions will start using the libc versions in the !SHARED case.
This is harmless at the moment because the objects are identical
except for their names.
Some of these duplicates could be removed from libm.so too, but I
avoided that in the interest of retaining an internal reference if at
all those functions get used within libm in future.
Reviewed-by: Paul Zimmermann <Paul.Zimmermann@inria.fr>
Diffstat (limited to 'libio')
0 files changed, 0 insertions, 0 deletions