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 _______________________________________________ devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
