devel March 2024

devel@uclibc-ng.org

8 participants
15 discussions

by Waldemar Brodkorb

Hi, I released a new version of uClibc-ng today. A lot of bugfixing for riscv32/riscv64 were done. Riscv32 is now fully supported. Riscv64 C++ applications are working now. Also explicit_bzero and reallocarray were added from musl libc. This time big thanks go to sorear for fixing all the riscv problems. Have fun, Waldemar

8 months

Time issues?

by Kevin Ingwersen

Hello there! After successfuly building my OpenADK image and launching into an mksh shell, I noticed that some programs behaved very, very weirdly. Especially in terms of time. For instance, take this `ps` (coreutils) output: # ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 99 Mar02 pts/0 1158050441-07:00:15 /bin/mksh -il root 40 1 99 Mar02 pts/0 1158050441-07:00:15 ps -ef It never changes, ever. However, `date` reports the time correctly: root@d6571a5cd187:/ # date "+%s" 1709916714 But Git and even GCC all hang and behave weirdly. Git can't even fetch a basic repo, because it believes the time in the index to be totally wrong. Do you have an idea what this is caused by? And yes, I did change my timezone with the TZ environment variable, too: root@d6571a5cd187:/ # export TZ="Europe/Berlin" root@d6571a5cd187:/ # date "+%s" 1709916972 root@d6571a5cd187:/ # ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 99 Mar02 pts/0 1158050441-07:00:15 /bin/mksh -il root 42 1 99 Mar02 pts/0 1158050441-07:00:15 ps -ef The container runs with --previleged, so I thought to just change the time: root@d6571a5cd187:/ # ntpclient -h ptbtime1.ptb.de -s 45357 61036.066 22575.0 24.0 -16383.9 15.3 4056424 root@d6571a5cd187:/ # ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 99 Mar02 pts/0 1158050441-07:00:15 /bin/mksh -il root 44 1 99 Mar02 pts/0 1158050441-07:00:15 ps -ef My only lead is that part of the time is wrong... I attached my OpenADK and Kernel config, and even extracted the generated uClibc-ng config from the build too (well, from the toolchain build). Also, I did try to just mount the /etc files into the container as well, but that did not help apparently. Any idea what's going wrong here or how I could debug this? Thanks! Kind regards, Ingwie

8 months, 1 week

Comatibility with older Linux kernel (2.6.33.7)

by Grant Edwards

I have an ARM9 platform that's running a pretty old Linux kernel (2.6.33.7 built with GCC 4.6.3). It's currently using a buildroot user-space built with that same compiler and uClibc 0.9.30. Moving to a newer kernel is not an option because of performance issues. Using a significantly newer version of GCC to build the kernel would also require more than a little kernel hacking. So I probably have to stick with the existing kernel build. For various reasons, updating to recent versions of a few user-space packages might be required. Are there likely to be compatibility problems building/running a user-space (e.g. with buildroot) using a recent toolchain (gcc 12.3, uClib-ng 1.0.45) for user-space and a kernel that old? -- Grant

8 months, 2 weeks

[PATCH] Add time64 support to OpenRISC.

by Dmitry Chestnykh

Signed-off-by: Dmitry Chestnykh <dm.chestnykh(a)gmail.com> --- extra/Configs/Config.in | 1 + libc/sysdeps/linux/or1k/bits/kernel_stat.h | 37 +++++++++++++++++++ .../linux/or1k/bits/uClibc_arch_features.h | 3 -- 3 files changed, 38 insertions(+), 3 deletions(-) create mode 100644 libc/sysdeps/linux/or1k/bits/kernel_stat.h diff --git a/extra/Configs/Config.in b/extra/Configs/Config.in index c7c502040..ded1f72c9 100644 --- a/extra/Configs/Config.in +++ b/extra/Configs/Config.in @@ -1028,6 +1028,7 @@ config UCLIBC_USE_TIME64 bool "Use *time64 syscalls instead of 32bit ones (if possible)" depends on TARGET_arm || \ (TARGET_mips && !CONFIG_MIPS_N64_ABI) || \ + TARGET_or1k || \ TARGET_powerpc || \ TARGET_xtensa # TODO: add support for other architectures diff --git a/libc/sysdeps/linux/or1k/bits/kernel_stat.h b/libc/sysdeps/linux/or1k/bits/kernel_stat.h new file mode 100644 index 000000000..cec44ecfc --- /dev/null +++ b/libc/sysdeps/linux/or1k/bits/kernel_stat.h @@ -0,0 +1,37 @@ +#ifndef _BITS_STAT_STRUCT_H +#define _BITS_STAT_STRUCT_H + +#if defined(__UCLIBC_USE_TIME64__) +#include "internal/time64_helpers.h" +#endif + +struct kernel_stat { + unsigned long st_dev; /* Device. */ + unsigned long st_ino; /* File serial number. */ + unsigned int st_mode; /* File mode. */ + unsigned int st_nlink; /* Link count. */ + unsigned int st_uid; /* User ID of the file's owner. */ + unsigned int st_gid; /* Group ID of the file's group. */ + unsigned long st_rdev; /* Device number, if device. */ + unsigned long __pad1; + long st_size; /* Size of file, in bytes. */ + int st_blksize; /* Optimal block size for I/O. */ + int __pad2; + long st_blocks; /* Number 512-byte blocks allocated. */ +#if defined(__UCLIBC_USE_TIME64__) + struct __ts32_struct __st_atim32; + struct __ts32_struct __st_mtim32; + struct __ts32_struct __st_ctim32; +#else + struct timespec st_atim; + struct timespec st_mtim; + struct timespec st_ctim; +#endif + unsigned int __unused4; + unsigned int __unused5; +}; + +#define kernel_stat64 kernel_stat + +#endif /* _BITS_STAT_STRUCT_H */ + diff --git a/libc/sysdeps/linux/or1k/bits/uClibc_arch_features.h b/libc/sysdeps/linux/or1k/bits/uClibc_arch_features.h index a9560b0b9..e11e71f88 100644 --- a/libc/sysdeps/linux/or1k/bits/uClibc_arch_features.h +++ b/libc/sysdeps/linux/or1k/bits/uClibc_arch_features.h @@ -14,9 +14,6 @@ /* can your target use syscall6() for mmap ? */ #define __UCLIBC_MMAP_HAS_6_ARGS__ -/* does your target use statx */ -#undef __UCLIBC_HAVE_STATX__ - /* does your target have a broken create_module() ? */ #undef __UCLIBC_BROKEN_CREATE_MODULE__ -- 2.44.0

8 months, 3 weeks

Target GCC compiled via OpenADK can't find dl_iterate_phdr

by Kevin Ingwersen

Hello there! Apologies if this is going into the wrong list, but I honestly was n't sure,e specially since this very issue was discussed a long time ago - found an exchange about this in the archive through Google - so I ended up just posting it here. I am currently building a toolset for RISC-V to use as a rootfs for a Docker Container that can then be used as a Jenkins agent to eventually build my way through Alpine's abuild/aports, so that I can reconstruct the alpine:3.19 image, but for RISC-V (there are only snapshots and the :edge image, right now). Most things built just fine; kernel, toolchain and alike. But when it tries to configure libatomic for the target, this happens: configure:14906: riscv64-openadk-linux-uclibc-cc -o conftest -g -O2 -g -Os -fno-sync-libcalls -pthread conftest.c >&5/nvme/opt/openadk/toolchain_generic-riscv64_uclibc-ng/usr/lib/gcc/riscv64-openadk-linux-uclibc/13.2.0/../../../../riscv64-openadk-linux-uclibc/bin/ld: /nvme/opt/openadk/toolchain_generic-riscv64_uclibc-ng/usr/lib/gcc/riscv64-openadk-linux-uclibc/13.2.0/libgcc.a(unwind-dw2-fde-dip.o): in function `_Unwind_Find_FDE': (.text+0x1adc): undefined reference to `dl_iterate_phdr' collect2: error: ld returned 1 exit status configure:14906: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU Atomic Library" | #define PACKAGE_TARNAME "libatomic" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU Atomic Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libatomic/" | #define PACKAGE "libatomic" | #define VERSION "1.0" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define LT_OBJDIR ".libs/" | #define IFUNC_RESOLVER_ARGS void | #define STDC_HEADERS 1 | #define STRING_WITH_STRINGS 1 | #define HAVE_INT1 1 | #define HAVE_INT2 1 | #define HAVE_INT4 1 | #define HAVE_INT8 1 | #define HAVE_INT16 1 | #define HAVE_ATOMIC_LDST_1 1 | #define HAVE_ATOMIC_LDST_2 1 | #define HAVE_ATOMIC_LDST_4 1 | #define HAVE_ATOMIC_LDST_8 1 | #define HAVE_ATOMIC_LDST_16 0 | #define HAVE_ATOMIC_TAS_1 1 | #define HAVE_ATOMIC_TAS_2 1 | #define HAVE_ATOMIC_TAS_4 1 | #define HAVE_ATOMIC_TAS_8 1 | #define HAVE_ATOMIC_TAS_16 1 | #define HAVE_ATOMIC_EXCHANGE_1 1 | #define HAVE_ATOMIC_EXCHANGE_2 1 | #define HAVE_ATOMIC_EXCHANGE_4 1 | #define HAVE_ATOMIC_EXCHANGE_8 1 | #define HAVE_ATOMIC_EXCHANGE_16 0 | #define HAVE_ATOMIC_CAS_1 1 | #define HAVE_ATOMIC_CAS_2 1 | #define HAVE_ATOMIC_CAS_4 1 | #define HAVE_ATOMIC_CAS_8 1 | #define HAVE_ATOMIC_CAS_16 0 | #define HAVE_ATOMIC_FETCH_ADD_1 1 | #define HAVE_ATOMIC_FETCH_ADD_2 1 | #define HAVE_ATOMIC_FETCH_ADD_4 1 | #define HAVE_ATOMIC_FETCH_ADD_8 1 | #define HAVE_ATOMIC_FETCH_ADD_16 0 | #define HAVE_ATOMIC_FETCH_OP_1 1 | #define HAVE_ATOMIC_FETCH_OP_2 1 | #define HAVE_ATOMIC_FETCH_OP_4 1 | #define HAVE_ATOMIC_FETCH_OP_8 1 | #define HAVE_ATOMIC_FETCH_OP_16 0 | #define WORDSIZE 8 | /* end confdefs.h. */ | #include <pthread.h> | void *g(void *d) { return NULL; } | int | main () | { | pthread_t t; pthread_create(&t,NULL,g,NULL); | ; | return 0; | } configure:14922: riscv64-openadk-linux-uclibc-cc -o conftest -g -O2 -g -Os conftest.c -lpthread >&5 /nvme/opt/openadk/toolchain_generic-riscv64_uclibc-ng/usr/lib/gcc/riscv64-openadk-linux-uclibc/13.2.0/../../../../riscv64-openadk-linux-uclibc/bin/ld: /nvme/opt/openadk/toolchain_generic-riscv64_uclibc-ng/usr/lib/gcc/riscv64-openadk-linux-uclibc/13.2.0/libgcc.a(unwind-dw2-fde-dip.o): in function `_Unwind_Find_FDE': (.text+0x1adc): undefined reference to `dl_iterate_phdr' collect2: error: ld returned 1 exit status configure:14922: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU Atomic Library" | #define PACKAGE_TARNAME "libatomic" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU Atomic Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libatomic/" | #define PACKAGE "libatomic" | #define VERSION "1.0" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define LT_OBJDIR ".libs/" | #define IFUNC_RESOLVER_ARGS void | #define STDC_HEADERS 1 | #define STRING_WITH_STRINGS 1 | #define HAVE_INT1 1 | #define HAVE_INT2 1 | #define HAVE_INT4 1 | #define HAVE_INT8 1 | #define HAVE_INT16 1 | #define HAVE_ATOMIC_LDST_1 1 | #define HAVE_ATOMIC_LDST_2 1 | #define HAVE_ATOMIC_LDST_4 1 | #define HAVE_ATOMIC_LDST_8 1 | #define HAVE_ATOMIC_LDST_16 0 | #define HAVE_ATOMIC_TAS_1 1 | #define HAVE_ATOMIC_TAS_2 1 | #define HAVE_ATOMIC_TAS_4 1 | #define HAVE_ATOMIC_TAS_8 1 | #define HAVE_ATOMIC_TAS_16 1 | #define HAVE_ATOMIC_EXCHANGE_1 1 | #define HAVE_ATOMIC_EXCHANGE_2 1 | #define HAVE_ATOMIC_EXCHANGE_4 1 | #define HAVE_ATOMIC_EXCHANGE_8 1 | #define HAVE_ATOMIC_EXCHANGE_16 0 | #define HAVE_ATOMIC_CAS_1 1 | #define HAVE_ATOMIC_CAS_2 1 | #define HAVE_ATOMIC_CAS_4 1 | #define HAVE_ATOMIC_CAS_8 1 | #define HAVE_ATOMIC_CAS_16 0 | #define HAVE_ATOMIC_FETCH_ADD_1 1 | #define HAVE_ATOMIC_FETCH_ADD_2 1 | #define HAVE_ATOMIC_FETCH_ADD_4 1 | #define HAVE_ATOMIC_FETCH_ADD_8 1 | #define HAVE_ATOMIC_FETCH_ADD_16 0 | #define HAVE_ATOMIC_FETCH_OP_1 1 | #define HAVE_ATOMIC_FETCH_OP_2 1 | #define HAVE_ATOMIC_FETCH_OP_4 1 | #define HAVE_ATOMIC_FETCH_OP_8 1 | #define HAVE_ATOMIC_FETCH_OP_16 0 | #define WORDSIZE 8 | /* end confdefs.h. */ | #include <pthread.h> | void *g(void *d) { return NULL; } | int | main () | { | pthread_t t; pthread_create(&t,NULL,g,NULL); | ; | return 0; | } configure:14925: error: Pthreads are required to build libatomic I went and looked up what that function is, exactly, and learned quickly that this is caused by me having chosen a static build. That said, this was also already discussed: https://uclibc.uclibc.narkive.com/079V4ltx/dl-iterate-phdr-missing-in-libc So, I am at a loss on what to do right now. I changed my setting to also build dynamic objects, then cleaned uClibc-ng and rebuilt and then attempted again to let the normal build run. But, that too, did not help. My questions: - Is dl_iterate_phdr in libc.a? According to grep, it matches, but that doesn-ät mean much. - I am using the 1.0.46 version of uClibc as openADK selects that. - Is there anything I can do to fix this, or do I have to start over and just build with shared libraries? I honestly would not be surprised if GCC just didn#t want to be statically linked; static is the devil, after all. ;) Thanks and kind regards, Ingwie

8 months, 3 weeks

[PATCH] libpthread/linuxthreads: add missing string.h include in condvar.c

by Marcus Haehnel

Quelches a compiler warning by that memset was implicitly declared. --- libpthread/linuxthreads/condvar.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libpthread/linuxthreads/condvar.c b/libpthread/linuxthreads/condvar.c index 027aa8fc3..01359ac83 100644 --- a/libpthread/linuxthreads/condvar.c +++ b/libpthread/linuxthreads/condvar.c @@ -18,6 +18,7 @@ #include <errno.h> #include <sched.h> #include <stddef.h> +#include <string.h> #include <sys/time.h> #include "pthread.h" #include "internals.h" -- 2.43.0

8 months, 3 weeks

[PATCH] libpthread: Remove no longer valid attribute_unused

by Marcus Haehnel

The variable is used since 04a676f3c8d2443499f27612f69ee88e12089e61. --- libpthread/linuxthreads/condvar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libpthread/linuxthreads/condvar.c b/libpthread/linuxthreads/condvar.c index 949991ad7..027aa8fc3 100644 --- a/libpthread/linuxthreads/condvar.c +++ b/libpthread/linuxthreads/condvar.c @@ -273,7 +273,7 @@ int pthread_cond_broadcast(pthread_cond_t *cond) } libpthread_hidden_def(pthread_cond_broadcast) -int pthread_condattr_init(pthread_condattr_t *attr attribute_unused) +int pthread_condattr_init(pthread_condattr_t *attr) { memset (attr, '\0', sizeof (*attr)); return 0; -- 2.43.0

8 months, 3 weeks

[PATCH] libm/w_j0f.c: Call correct ieee754 function

by Marcus Haehnel

The j0f implementation should, like the other float implementations, call the __ieee754_y0 variant for doubles. A float variant is not declared and leads to a compile error on c99 builds. --- libm/w_j0f.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libm/w_j0f.c b/libm/w_j0f.c index 89821bc98..496e098cd 100644 --- a/libm/w_j0f.c +++ b/libm/w_j0f.c @@ -63,6 +63,6 @@ y0f (float x) return __kernel_standard_f (x, x, 135); } # endif /* __UCLIBC_HAS_FENV__ */ - return (float) __ieee754_y0f ((double) x); + return (float) __ieee754_y0 ((double) x); } #endif /* __DO_XSI_MATH__ */ -- 2.43.0

8 months, 3 weeks

uClibc-ng release 1.0.46

by Waldemar Brodkorb

Hi, yesterday I released uClibc-ng 1.0.46. The most important change is time64 support for a lot of 32 Bit architectures like ARM, MIPS, PPC32, ... Thanks a lot Dmitry for all of your patches and hard work. Furthermore riscv32 with MMU can now be used. best regards Waldemar

8 months, 3 weeks

Building on RISC-V (riscv64gc-linux)

by Kevin Ingwersen

Hello there! I am having a bit of a "moment" here, trying to build ucLibC on my VisionFive2. I have configured most of the things I would like the library to feature, but when I try to actually build it, it can not find my headers properly. I have tried /usr, /usr/include and also used find to locate the folders that it was looking for, but to no avail. It is either linux/errno.h, asm/errno.h or asm/unistd.h that can not be found. The kernel is self-built (since the upstream currently lacks two patches required for full SoC support) off the 6.6.0 branch and headers are installed to their standard location, including /usr/src/linux-headers-$(uname -r). What is the expected structure to be found under .config's KERNEL_HEADERS? Thank you and kind regards, Ingwie

8 months, 3 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel March 2024