4 Dec
2017
4 Dec
'17
7:59 p.m.
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(a)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
4 Dec
4 Dec
8:11 p.m.
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
9:14 p.m.
On 12/04/2017 15:11, Waldemar Brodkorb wrote:
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(a)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,
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.
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.
9:38 p.m.
Hi,
Joshua Kinard wrote,
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.
On 12/04/2017 15:11, Waldemar Brodkorb wrote:
Exactly.
Hi Joshua,
Joshua Kinard wrote,
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.
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 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. 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
2329
days inactive
2329
days old
3 comments
2 participants
participants (2)
-
Joshua Kinard -
Waldemar Brodkorb