Hello,
Sorry for the bother but I’ve been struggling with compiling uclibc-ng. All I did was clone; make defconfig; make.
I get the following error:
CC ldso/ldso/ldso.oS
In file included from ./include/bits/posix1_lim.h:152:0,
from ./include/limits.h:144,
from ./include/sys/param.h:25,
from ./ldso/include/ldso.h:43,
from ldso/ldso/ldso.c:32:
./include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No such file or directory
compilation terminated.
Makerules:370: recipe for target 'ldso/ldso/ldso.oS' failed
make: *** [ldso/ldso/ldso.oS] Error 1
I’ve tried to remove -nostdinc, the compilation then proceeds but with no success. I also tried to install the following packages: kernel-package, linux-libc-dev, binutils, libc-dev-bin, linux-headers-4.10.0-35 and linux-headers-generic.
Can anyone help?
Best regards,
Daniel Dubinsky
Hello,
This is a followup to the ("f764bcffe" or1k: syscall: Pass arguments on the
stack) patch which fixes the issue where the definition of syscall() in unistd.h
and the common implementation in uclibc-ng don't match.
This series allows the implementation to match the definition and then goes on
to remove generic implementations used by or1k, nds32 and arc.
-Stafford
Stafford Horne (4):
syscall: Make common implementation match unistd.h
or1k: Use new common syscall() implementation
nds32: Use new common syscall() implementation
arc: Use new common syscall() implementation
libc/sysdeps/linux/arc/Makefile.arch | 2 +-
libc/sysdeps/linux/arc/syscall.c | 17 -----------------
libc/sysdeps/linux/common/syscall.c | 18 +++++++++++++++++-
libc/sysdeps/linux/nds32/Makefile.arch | 4 ++--
libc/sysdeps/linux/nds32/syscall.c | 28 ----------------------------
libc/sysdeps/linux/or1k/Makefile.arch | 2 +-
libc/sysdeps/linux/or1k/syscall.c | 32 --------------------------------
7 files changed, 21 insertions(+), 82 deletions(-)
delete mode 100644 libc/sysdeps/linux/arc/syscall.c
delete mode 100644 libc/sysdeps/linux/nds32/syscall.c
delete mode 100644 libc/sysdeps/linux/or1k/syscall.c
--
2.13.6
When ran on ARC, these tests would ocassionally fail
| [ARCLinux]# for i in 1 2 3 4 5 ; do ./tst-cancel2; echo $?; done
| write succeeded
| result is wrong: expected 0xffffffff, got 0x1
| 1 <-- fail
| 0 <-- pass
| 0 <--- pass
| 0 <-- pass
| write succeeded
| result is wrong: expected 0xffffffff, got 0x1
| 1 <-- fail
Same test (which originated form glibc) doesn't fail in glibc builds.
Turns out there's a subtle race in uclibc version
The test creates a new thread, makes it do a looong write call, and
parent then cancels the thread, expecting it to unwind out of write
call cleanly. However the write (even for 10k bytes) could fnish befor
eparent gets a chance ti run and/or cancel - causing the occasional
failire.
Cc: Cupertino Miranda <cmiranda(a)synopsys.com>
Fix this subtelty by making it write not just once but forever.
Signed-off-by: Vineet Gupta <vgupta(a)synopsys.com>
---
test/nptl/tst-cancel2.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/test/nptl/tst-cancel2.c b/test/nptl/tst-cancel2.c
index 45c9e8ea957a..08dd13b10f37 100644
--- a/test/nptl/tst-cancel2.c
+++ b/test/nptl/tst-cancel2.c
@@ -32,11 +32,7 @@ tf (void *arg)
write blocks. */
char buf[100000];
- if (write (fd[1], buf, sizeof (buf)) == sizeof (buf))
- {
- puts ("write succeeded");
- return (void *) 1l;
- }
+ while (write (fd[1], buf, sizeof (buf)) > 0);
return (void *) 42l;
}
--
2.7.4
Hi Waldemar,
I've recently encountered an issue with broken posix_spawn in uClibc-ng
1.0.26, which made cups 2.2.[46] unusable. Looking at commit
71b3a63b641716165f664cf112be0673a122cea0, I see that it should be fixed in
1.0.27. I have a small test code that illustrates the problem with
posix_spawn, which works fine with GNU lib C, but fails with uClibc-ng
1.0.26 (see posix_spawn.c attached). If I remove POSIX_SPAWN_SETSIGDEF
flag, it works OK. I can't test it with 1.0.27 yet, could you please verify
that it works?
Also, if it works fine, another question. What is the proper macro test for
working posix_spawn (uClibc-ng version 1.0.27+)?
Thank you,
Alex
Hi Alexey,
the attached patch fixes at least 3 test suite errors for me.
tst-cancel20/21/4.
Tested with latest 2017.09 ARC binutils/gcc.
Okay to apply?
best regards
Waldemar
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
