devel

devel@uclibc-ng.org

2 participants
1164 discussions

Start a nNew thread

Re: [uclibc-ng-devel] thumb_swp/thumb_swpb
by Florian La Roche 04 Jun '18

04 Jun '18

1 0

thumb_swp/thumb_swpb
by Florian La Roche 30 May '18

30 May '18

Hello uclibc-ng/buildroot developers, compiling buildroot with thumb-instructions and gcc-8.1 results in an error due to the swp{,b} assembler instruction. Searching within buildroot, this thumb_swp* function is never used anywhere (but this is a very limited search). The add commit message for this refers to other libraries using this function, but no real specific data. Maybe this can be removed altogether? best regards, Florian La Roche Geschäftsführung: Susanne Kunschert, Thomas Pilz Pilz GmbH & Co. KG, Sitz: Ostfildern, HRA 210 893, Amtsgericht Stuttgart Kompl. Ges. Peter Pilz GmbH, Sitz: Ostfildern, HRB 210 612, Amtsgericht Stuttgart Umsatzsteuer: ID-Nr. DE 145 355 773, WEEE-Reg.-Nr. DE 71636849 This email is intended solely for the use of the named address(es). Any unauthorised disclosure, copying or distribution of these confidential information contained therein, or the taking of any action based on it, is prohibited. The sender disclaims any liability for the integrity of this email. Legally binding declarations must be in written form. Umweltschutz liegt uns am Herzen! - Bitte denken Sie an unsere Umwelt, bevor Sie diese E-Mail drucken. We do care about the environment! - Please consider the environment before printing this e-mail.

2 2

Creating a pull request
by Daniel Dubinsky 29 May '18

29 May '18

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

2 3

1.0.30 release reports
by Waldemar Brodkorb 10 May '18

10 May '18

Hi, as after every uClibc-ng release I try to run a full build and try to generate test results of the release: https://downloads.uclibc-ng.org/reports/1.0.30/ The toolchains for ARC architecture where back to Synopsys arc-2018.03-rc1 instead of binutils/gcc from pstream. There we can see that the results for ARCv2 are getting better and under or equal 10 failures. The ARCv1 results are bad. (over 40). The newly added test results for c-sky are not bad, just ck610 seems to generate a lot of Bus errors. The other results showing no major regressions. The empty toolchain files are just a marker, that a toolchain could be produced without any runtime testing. The default Linux kernel used was bumped to 4.14 series. best regards Waldemar

1 0

Fwd: new uClibc-ng release
by Anthony G. Basile 29 Apr '18

29 Apr '18

These should be going to the list for archiving, so I'm forwarding it. On 4/29/18 8:32 AM, Dave Flogeras wrote: > Hey Anthony, > > Also I'd like to chime in what I learned during testing: since this release > of uclibc-ng-1.0.30 removes arcfour, rebuilding at least openssl/openssh > immediately might warrant a huge warning for upgrading Gentoo users. My > system is built on one machine and deployed as binaries onto the target, so > having a non-working SSH/rsync after upgrading uclibc-ng is a bummer. > Portage (Python) also squawks when importing a module until python is > rebuilt, but it doesn't seem to prevent portage from working. > > Dave > > On Sun, Apr 29, 2018 at 6:24 AM, Waldemar Brodkorb <wbx(a)uclibc-ng.org> > wrote: > >> Hi Anthony, >> >> Dave and I fixed the dlclose() issue and we think it could >> be a good time to have new stage3 with 1.0.30? >> I can test on real hardware for every supported architecture. >> >> Thanks in advance >> Waldemar >> >> > Yes I noticed that, and it is serious, but this is the least of my worries right now. The LDPATH search is totally broken on amd64. ldconfig shows that libstdc++.so and libgcc_s.so are in the search path: # ldconfig -p | grep libstdc++.so libstdc++.so.6 (libc0) => /usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0/libstdc++.so.6 libstdc++.so (libc0) => /usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0/libstdc++.so # ldconfig -p | grep libgcc_s.so libgcc_s.so.1 (libc0) => /usr/lib/gcc/x86_64-gentoo-linux-uclibc/6.4.0/libgcc_s.so.1 And yet a test c++ program cannot locate those libraries: # ldd test libstdc++.so.6 => not found libgcc_s.so.1 => not found libc.so.0 => /lib//libc.so.0 (0x7f6bfb067000) ld64-uClibc.so.0 => /lib/ld64-uClibc.so.0 (0x7f6bfb516000) @Waldemar, the issue is not anything you suggested in your previous email. What might you have touched in ld64-uClibc.so or libc.so itself that would affect the search path? If its any help, I hit the dlclose() issue many years ago (and might have been the first to report it, I'm not sure). There was some size issue wrt 64 vs 32 that cause an issue there. I wonder if in fixing that maybe you broke LDPATH? -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness(a)gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA

3 4

uClibc-ng 1.0.30 released
by Waldemar Brodkorb 29 Apr '18

29 Apr '18

Hi, I released uClibc-ng 1.0.30 today. Many thanks to Dave Flogeras who pushed me to my limits to get the annyoing dlclose() issue fixed. Short summary: 748422473 (HEAD -> master, tag: v1.0.30, origin/master, origin/HEAD, github/master) bump for release 1.0.30 3f100edcc mention Tile architecture 14be0795f libdl: first execute all destructors, then munmap library 132decd2a libdl: calculate the length for second parameter of munmap. 04a676f3c linuxthreads: implement pthread_condattr_{s,g}etclock() d86bd3529 libdl: end must be bigger than start 8d7723d1c libdl: remove gcc warnings d89de5cba libiconv: remove function, which is not available w/o libiconv a4 macros 35105679b libdl: fix problem with unmapping eb560ac79 libdl: better checking and logging for ctors/dtors 744e199bb libdl: remove dead code 0c8cc6e7e libdl: remove LDSO_NO_CLEANUP 07dfe7c86 libdl: cleanup old inline changelog aaf1b2f56 Revert "libdl: fix dlclose() issue" 343fb004d common/sendfile.c: bugfix can't support offset is NULL 2d8a38e1a Revert "common/sendfile.c: bugfix can't support offset is NULL" ad6c75c47 lseek.c: bugfix ltp lseek01.c b00fd230e common/sendfile.c: bugfix can't support offset is NULL f42d18f06 or1k: add F_{DUPFD_CLOEXEC, SETPIPE_SZ, GETPIPE_SZ} 161d237ad use __NR_newfstatat only for modern Linux architectures 91e21d251 hppa: fix runtime issues 8be3a69f1 csky: support bsd-setjmp and bsd-_setjmp. bf4c2d242 libdl: fix dlclose() issue 5bdc2b4de Revert "Revert "libdl: fix size parameter when unmap library in dlclose"" 490e84f5e tile: add basic support for tilegx 6e627523e sparc32: Add nop before __startcontext to stop unwinding 01e9f2f20 utils: fix compile of msgfmt/msgmerge c03cce8f7 fenv: only allow for ppc e500 best regards Waldemar

2 3

pthread_contattr_setclock() in linuxthreads ?
by Thomas Petazzoni 17 Apr '18

17 Apr '18

Hello, In Buildroot, a number of packages fail to build because pthread_contattr_setclock() is not implemented in linuxthreads (only in NPTL). So far, we've worked around this problem by adding a dependency on NPTL in packages that use pthread_condattr_setclock(), but it would be nice if uClibc-ng could support this function in linuxthreads as well. Is there anything that prevents this from being supported in linuxthreads ? Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com

2 1

[PATCH v2] common/sendfile.c: bugfix can't support offset is NULL
by Guo Ren 16 Apr '18

16 Apr '18

In ltp testcase sendfile08.c, it use offset=NULL to test the api. PATCH V2: fixup the stupid missing check in the end. Sorry for lose test. See "man sendfile" and it really support offset is NULL. Signed-off-by: Guo Ren <ren_guo(a)c-sky.com> --- libc/sysdeps/linux/common/sendfile.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libc/sysdeps/linux/common/sendfile.c b/libc/sysdeps/linux/common/sendfile.c index af05ba4..f0372c1 100644 --- a/libc/sysdeps/linux/common/sendfile.c +++ b/libc/sysdeps/linux/common/sendfile.c @@ -40,7 +40,7 @@ ssize_t sendfile(int out_fd, int in_fd, __off_t *offset, size_t count) return -1; } - if (offset == NULL || (int)offset < 0) { + if ((int)offset < 0) { __set_errno(EFAULT); return -1; } @@ -54,7 +54,7 @@ ssize_t sendfile(int out_fd, int in_fd, __off_t *offset, size_t count) res = INLINE_SYSCALL(sendfile64, 4, out_fd, in_fd, off, count); - if (res >= 0) + if (res >= 0 && offset != NULL) *offset = off64; return res; -- 2.7.4

1 0

dlclose() issue
by Waldemar Brodkorb 15 Apr '18

15 Apr '18

Hi, I still having issues with dlclose(). Can anybody help me with this issue? This is a long standing bug and still not solved. Recently I reverted commit 952bb00f0b2eb576b0bf48c4f87018429a42e28d in commit 5bdc2b4dee516c8e4d7ba9f5d26c9bf31418b52f, because some Gentoo people reported issues with preparing stage1/stage2 images with this patch applied. The problem which was fixed by accident with this commit is segfaults in dlclose when running apache2 or php -m. But the munmap() calls where just wrong. Then I thought I found a real fix for the dlclose() segfaults in the old uClibc bugtracker https://bugs.busybox.net/show_bug.cgi?id=6158 I tested and pushed commit bf4c2d242f587700e3eb2ffd5721ddaf3cdbc7e5. But this change introduces a regression when running the uClibc-ng testsuite. When running testscope test, the test case fails, as the function registered via atexit(), is no longer available after dlclose() is executed. Why the dlclose() function is so extremely complex in uClibc and glibc? Musl seems to do nothing in dlclose() :/ Any help is really appreciated. best regards Waldemar

1 1

[PATCH] lseek.c: bugfix ltp lseek01.c
by Guo Ren 13 Apr '18

13 Apr '18

Ref the implement from the glibc and high=0 seems so bad. Signed-off-by: Guo Ren <ren_guo(a)c-sky.com> --- libc/sysdeps/linux/common/lseek.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libc/sysdeps/linux/common/lseek.c b/libc/sysdeps/linux/common/lseek.c index 33df822..80d6931 100644 --- a/libc/sysdeps/linux/common/lseek.c +++ b/libc/sysdeps/linux/common/lseek.c @@ -19,8 +19,9 @@ off_t __NC(lseek)(int fd, off_t offset, int whence) { #if __WORDSIZE == 32 __off64_t result; - __off_t high = 0; - return INLINE_SYSCALL(llseek, 5, fd, high, offset, &result, whence) ?: result; + return INLINE_SYSCALL(llseek, 5, fd, + (long) (((uint64_t) (offset)) >> 32), + (long) offset, &result, whence) ?: result; #else return lseek64(fd, offset, whence); #endif -- 2.7.4

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel