April 2018 - devel - example.com

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

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

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

13 Apr '18

In ltp testcase sendfile08.c, it use offset=NULL to test the api. 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 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libc/sysdeps/linux/common/sendfile.c b/libc/sysdeps/linux/common/sendfile.c index af05ba4..def98da 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; } -- 2.7.4

2 1

[PATCH] or1k: add F_{DUPFD_CLOEXEC, SETPIPE_SZ, GETPIPE_SZ}
by Thomas Petazzoni 13 Apr '18

13 Apr '18

Those definitions exist on all other architectures, but were not present in or1k specific headers when or1k support was merged. On the kernel side, their support is completely architecture independent, so we just need those definitions to make those fcntl() calls available on or1k. Signed-off-by: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> --- libc/sysdeps/linux/or1k/bits/fcntl.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/libc/sysdeps/linux/or1k/bits/fcntl.h b/libc/sysdeps/linux/or1k/bits/fcntl.h index bd6a8c511..a82ede424 100644 --- a/libc/sysdeps/linux/or1k/bits/fcntl.h +++ b/libc/sysdeps/linux/or1k/bits/fcntl.h @@ -102,6 +102,10 @@ # define F_SETLEASE 1024 /* Set a lease. */ # define F_GETLEASE 1025 /* Enquire what lease is active. */ # define F_NOTIFY 1026 /* Request notfications on a directory. */ +# define F_DUPFD_CLOEXEC 1030 /* Duplicate file descriptor with + close-on-exit set on new fd. */ +# define F_SETPIPE_SZ 1031 /* Set pipe page size array. */ +# define F_GETPIPE_SZ 1032 /* Get pipe page size array. */ #endif /* For F_[GET|SET]FL. */ -- 2.14.3

2 1

Re: [uclibc-ng-devel] compile uclibc with retpoline switch
by Waldemar Brodkorb 05 Apr '18

05 Apr '18

Hi, Ata, John (US) wrote, > Hi all, > > > > With Spectre variant 2 (CVE-2017-5715), gcc has been updated to avoid branch > prediction problems via the retpoline patch. Specifically, by using either – > mindirect-branch=thunk-inline or –mindirect-branch=thunk or –mindirect-branch- > thunk-external, the compiler will convert indirect branches and function > returns to call and return thunks thus avoiding speculative execution in those > cases. Of course, there is a performance penalty depending on the exact > argument used. Has anyone compiled uclibc with one of those switches? I didn't tried it, yet. You might be the first :) Any issues seen with that? best regards Waldemar

3 2