aboutsummaryrefslogtreecommitdiff
path: root/secure/lib/libdes/(public-mirror)
diff options
context:
space:
mode:
authorPiotr Kubaj <pkubaj@FreeBSD.org>2026-08-09 09:02:40 +0000
committerPiotr Kubaj <pkubaj@FreeBSD.org>2026-08-09 09:07:30 +0000
commit185a03ad8aa84baf6c644688fc7687d2a3ebf1c5 (patch)
tree1fc129f8b95ca3909c70c5ae0d18b39fc550b856 /secure/lib/libdes/(public-mirror)
parent776ba7badef0ef1d6d097bf300cdcd6fc13478d4 (diff)
libgcc_s: export the IEEE-128 long double runtime on powerpc64leHEADmain
On powerpc64le with IEEE-128 long double, the long-double compiler-runtime helpers are the *kf* soft-float functions (built from the tf sources, renamed via -D in lib/libcompiler_rt/Makefile.inc) plus the complex multc3/__divtc3. They are compiled into libgcc_s.so by the powerpc64le SRCF block, but were never added to Symbol.map, so they stayed local and unexported. Every other IEEE-128 architecture already exports its scalar long-double runtime -- aarch64 and riscv list the tf helpers in GCC_4.6.0. powerpc64le was simply missed. Because the helpers are unexported, any clang-built shared library that uses long double leaves them undefined (permitted in a DSO), and linking an executable against that DSO then fails under lld's default --no-allow-shlib-undefined. For example science/harminv fails to link its binary against its own libharminv.so with undefined multc3/divtc3; at -O0, mulkf3/addkf3/__subkf3/__unordkf2 appear as well. Export the full runtime, gated on the PowerPC-specific LONG_DOUBLE_IEEE128 predefine so no other architecture is affected: complex multc3/divtc3 in GCC_4.0.0 (beside the other complex mul*c3), and the 28 scalar *kf* functions in GCC_7.0.0. Node placement follows glibc/gcc symbol-versioning history. Differential Revision: https://reviews.freebsd.org/D58248
Diffstat (limited to 'secure/lib/libdes/(public-mirror)')
0 files changed, 0 insertions, 0 deletions