Hi Joshua, Joshua Kinard wrote,
Similar to the thread regarding build failures w/ DO_XSI_MATH disabled, I think there is another breakage with the new FENV bits that were added by commit ea38f4d89c96, which when built natively on an existing uclibc-ng-1.0.26 chroot yield these failures:
LD libuClibc-0.1.0.27.so libc/libc_so.a(w_acos.os): In function `__GI_acos': w_acos.c:(.text+0x74): undefined reference to `feraiseexcept' libc/libc_so.a(k_standardl.os): In function `__kernel_standard_l': k_standardl.c:(.text+0x10): undefined reference to `feholdexcept' k_standardl.c:(.text+0x70): undefined reference to `fesetenv' collect2: error: ld returned 1 exit status make: *** [libc/Makefile.in:77: lib/libc.so] Error 1
I am not sure why these symbols go missing. Possibly something related to kernel headers? My chroot environment has kernel headers from 4.13 installed, so I am thinking this isn't the issue. I have both DO_C99_MATH and DO_XSI_MATH enabled, using legacy NAN (not 2008), and various other glibc-compatibility tweaks enabled. uclibc-ng-1.0.26 built fine -- the only real issue there was my previously-reported xfsprogs build failure.
I think in commit ea38f4d89c96 the first time fenv functionality is used in libm and so it is triggering the linking issue for architectures where UCLIBC_HAS_FENV might be enabled even when not supported by uClibc-ng, yet. Blueness from Gentoo reported a similar issue for amd64, where I added support in commit edce88cfef2f2a62647c2ab9536ca29694fab292. Furthermore I only allow to select UCLIBC_HAS_FENV for supported architectures in commit 82162fc661cc19890c982462e3f88c1a86e4a64c.
So either cherry-pick the commits or just disable UCLIBC_HAS_FENV as it is not yet supported for MIPS. You have it enabled, right?
I also read earlier that it is considered uncommon to build uclibc-ng natively. I'd like to call that into question and recommend that native builds be tested in some capacity before new releases are made. An existing environment should be capable of upgrading itself.
Okay, let's say it is uncommon to compile uClibc-ng on deeply embedded hardware. In your case with vintage MIPS hardware it is okay to natively compile and I will accept any bug reports when issues come up.
best regards Waldemar