uclibc-ng-1.0.27 commit ea38f4d89c96 breaks native build on fenv* bits
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 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. -- Joshua Kinard Gentoo/MIPS kumba@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
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
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 kumba@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
Hi, Joshua Kinard wrote,
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.
Exactly.
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.
Correct. It is in master.
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.
It might be that just copying ./sysdeps/mips/fpu from glibc to uClibc-ng libm/mips and adding a Makefile.arch might be enough. It was not so hard to do it for x86_64, but I must confess that I am not really sure how to verify the code at runtime.
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.
Buildroot and LEDE does not contain native gcc and header packages. I am supporting native gcc in OpenADK and have some support to run automatic tests with embedded-test.sh, but most qemu tests would require a NFS share as the space is limited. I planned to regulary run the test suite on real hardware, but I had no time yet to finish automatic poweron/poweroff of my devices.
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.
Come on, SGI hardware never dies ;) I need to powerup my Indies and O2's to verify my word :) There are octeon64 routers or lemote yeelong laptops, which might be useful for MIPS hacking. Or imgtec ci20/ci40 embedded boards. best regards Waldemar
participants (2)
-
Joshua Kinard -
Waldemar Brodkorb