Glibc - "undefined symbol: __sfp_handle_exceptions"

[NR]

A correction on my part for posting to the wrong ML, and now posting
here to continue the conversation...

On Mon, Jun 9, 2025 at 1:03 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
> On 09/06/25 12:16, NR wrote:
> > 1) Install kernel headers into empty directory
> > 2) Install glibc headers (and "touch" "<sysroot>/usr/include/gnu/stubs.h")
> > 3) Install LLVM runtime builtins
> > 4) Build glibc against sysroot
> >
> > ```
> > /<pathTo>/toolchain/bin/clang   -shared -static-libgcc -Wl,-O1
> > -Wl,-z,defs -Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2
> > -Wl,-z,pack-relative-relocs  -B/<pathTo>/build/csu/
> > -Wl,--version-script=/<pathTo>/build/libm.map -Wl,--undefined-version
> > -Wl,-soname=libm.so.6 -Wl,-z,relro -Wl,-z,now  -L/<pathTo>/build
> > -L/<pathTo>/build/math -L/<pathTo>/build/elf -L/<pathTo>/build/dlfcn
> > -L/<pathTo>/build/nss -L/<pathTo>/build/nis -L/<pathTo>/build/rt
> > -L/<pathTo>/build/resolv -L/<pathTo>/build/mathvec
> > -L/<pathTo>/build/support -L/<pathTo>/build/misc
> > -L/<pathTo>/build/debug -L/<pathTo>/build/nptl
> > -Wl,-rpath-link=/<pathTo>/build:/<pathTo>/build/math:/<pathTo>/build/elf:/<pathTo>/build/dlfcn:/<pathTo>/build/nss:/<pathTo>/build/nis:/<pathTo>/build/rt:/<pathTo>/build/resolv:/<pathTo>/build/mathvec:/<pathTo>/build/support:/<pathTo>/build/misc:/<pathTo>/build/debug:/<pathTo>/build/nptl
> > -o /<pathTo>/build/math/libm.so /<pathTo>/build/csu/abi-note.o
> > -Wl,--whole-archive /<pathTo>/build/math/libm_pic.a
> > -Wl,--no-whole-archive   -Wl,--start-group /<pathTo>/build/libc.so
> > /<pathTo>/build/libc_nonshared.a -Wl,--as-needed
> > /<pathTo>/build/elf/ld.so -Wl,--no-as-needed -Wl,--end-group
> > ld.lld: warning: attempt to reassign symbol 'exp2l' of version
> > 'GLIBC_2.2.5' to version 'GLIBC_2.4'
> > ld.lld: error: undefined symbol: __sfp_handle_exceptions
> >>>> referenced by e_sqrtf128.c
> >>>>               e_sqrtf128.os:(__ieee754_sqrtf128) in archive /<pathTo>/build/math/libm_pic.a
> > clang: error: linker command failed with exit code 1
> > ```
> >
> > I also found it odd that even though I set "LDFLAGS" to include
> > sysroot and "-v", it didn't produce ld.lld verbose output (only
> > clang). It does with other projects.
> > My CFLAGS were included in "config.make", but no LDFLAGS.
> >
> > I was trying to think where I've seen "undefined symbol" before and
> > just now remembered it was when I stripped binaries for musl and ended
> > up finding out the entry "_start" was ripped out.
> > That doesn't apply here I don't think, as no install even happened yet.
> >
> > I see other "attempt to reassign symbol" warnings and read about using
> > "-Wl,--undefined-version" to LDFLAGS, but that didn't make any
> > difference (not sure why it would since they aren't "undefined").
> >
> > A search led me to
> > https://inbox.sourceware.org/glibc-cvs/?t=20240410130446 with some
> > "sfp" related stuff.
> > I don't know when `sysdeps/x86_64/configure` ends up occurring.
> >
>
> The __sfp_handle_exceptions is used internally by x86_64 and powerpc64le for
> the soft-fp implementation (soft-fp/), used to implement float128
> support (or for the case of powerpc64le with -mabi=ieeelongdouble, the
> long double), and it is provided by *libgcc*.  Afaiu, this was a deliberate
> decision  since glibc is/was the main source for the soft-fp implementation;
> and for some targets glibc still supports such symbols as compat one, and
> using libgcc will result in duplicated symbol and required some hacks to
> make the build correct (like .wrap we do for sparc).
>
> The last time I tried to check glibc build with clang and llvm runtime I noted
> that compiler-rt does not provide __sfp_handle_exceptions, nor its soft-fp routines
> (for long double / _Float128) support floating point rounding mode different than
> default (FE_TONEAREST) nor floating point exceptions for some operation (like
> overflow/underflow or invalid operations). I think this is true even for
> today.
>
> In this experiment I used a glibc where I copied the gcc implementation
> (libgcc/config/i386/sfp-exceptions.c).  Sometime ago I tried to add a SSE
> only implementation on glibc (460ee50de054396cc9791ff4cfdc2f5029fb923d),
> but I had to revert it (f721171632d67f397e712db52b9ce36bb46fdd96).
>
> I think we recent minimum gcc version required to build glibc we can instead
> link against libgcc instead of resorting to our own soft-fp implementation.
> This would require some make changes to avoid doing this for some target
> (like powerpc).
>
> Another possibility would just to copy __sfp_handle_exceptions from libgcc
> to glibc for the ABI that requires it.
>
> On llvm side, one possibility would be to add __sfp_handle_exceptions for
> llvm-libgcc runtime.

Okay, so from what I'm gathering, the azanella/clang branch is
expected to NOT build successfully without libgcc being installed
first. So, my options are:
a) I build `libgcc` first (easiest route (supposedly))
b) I copy `https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/ia64/sfp-exceptions.c`
to `sysdeps/x86/fpu/` and add it somewhere in the `Makefile`
(shouldn't this just already be done in the azanella/clang branch
itself?)
c) I copy `https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/ia64/sfp-exceptions.c`
to `llvm-project/llvm-libgcc/` and add it somewhere in
`CMakeLists.txt` (probably not since I'd doubt llvm would want to
accept such a PR)
d) It's dead-in-the-water, and I should give musl another look (was in
a fiery discussion regarding it and systemd, but yocto seems made for
it)

I'll start with exploring b) when I'm rested, but am welcoming of
insight if I'm mistaken in any of my assumptions, or any further
advice.