On 12/04/2017 15:11, Waldemar Brodkorb wrote: > 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?
Yup, I did have UCLIBC_HAS_FENV enabled. It looks like I enabled in in 1.0.26 and it must've evaluated into a NOP and thus not generate any errors then. I probably glanced at the help text, but didn't notice the "note" indicating it is only supported by i386 at the time. I guess that 1.0.27 doesn't have commit 82162fc661cc included. Is adding this support just a matter of creating the necessary directories and copying files straight out of current glibc? I took a look at the x86_64 bits, and there's a mix of assembler included, which means a straight-forward cherrypick is probably not possible. It is my observation that floating-point on MIPS can be a bit of a strange animal. >> 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. SGI gear might be easily obtainable for "vintage" MIPS gear, but some common routers have enough RAM and flash storage that, if the development packages are included in the image (buildroot, lede, etc), it is theoretically possible that they could at least test a native build of uclibc-ng itself out. Arguably, an install being able to update itself, including a full rebuild of the system, would be nice. But yes, having dealt with old, heavily constrained platforms (Cobalt RaQ2) in the past, I know that this is not always feasible. Honestly, I do wish there were other classes of "workstation"-grade MIPS systems more easily available beyond SGI gear. It's only a matter of time before even SGI stuff will be hard to acquire and/or reliability of key components (such as power supplies) becomes questionable due to age. The PSU in my Octane has to be at least 10, if not 15 years old by now. One of these days, it either won't turn on, or I'll get a personalized fireworks display. At that point, I'm either hunting for a spare or learning how to desolder & replace capacitors. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic _______________________________________________ devel mailing list devel@uclibc-ng.org https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
