"Waldemar" == Waldemar Brodkorb wbx@uclibc-ng.org writes:
Hi Ben, patch applied and pushed.
What is the impact of this exactly? As far as I can see, this causes linking something using fork() on nommu to now generate a linker warning but no longer fail with a missing symbol.
Is that an improvement? Looking with my Buildroot glasses, I could imagine that such linker warnings could easily be missed in a big build, whereas a linker error naturally not.
best regards Waldemar
Ben Wolsieffer wrote,
From: Ben Wolsieffer Ben.Wolsieffer@hefring.com
fork() can be implemented using either the fork or clone syscalls on MMU systems. Therefore the stub is only generated if neither __NR_fork nor __NR_clone are defined. The stub code manually undefines __NR_fork on no-MMU systems in an attempt to enable the stub, but this doesn't work because __NR_clone is still defined. It is not appropriate to undefine __NR_clone because clone is available on no-MMU, it is just not capable of implementing fork.
This patch directly enables the fork stub if __ARCH_USE_MMU__ is not defined. This eliminates the need to undefine __NR_fork, so this code is removed
Signed-off-by: Ben Wolsieffer ben.wolsieffer@hefring.com
libc/sysdeps/linux/common/stubs.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libc/sysdeps/linux/common/stubs.c b/libc/sysdeps/linux/common/stubs.c index c17e509b9..634dcde0d 100644 --- a/libc/sysdeps/linux/common/stubs.c +++ b/libc/sysdeps/linux/common/stubs.c @@ -34,10 +34,6 @@ __attribute_used__ static int ret_enosys_stub(void) link_warning(stub, #stub ": this function is not implemented") \ strong_alias(ret_enosys_stub, stub)
-#ifndef __ARCH_USE_MMU__ -# undef __NR_fork -#endif
#ifdef __arm__ # define __NR_fadvise64_64 __NR_arm_fadvise64_64 # define __NR_fadvise64 __NR_arm_fadvise64_64 @@ -120,7 +116,7 @@ make_stub(fgetxattr) make_stub(flistxattr) #endif
-#if !defined __NR_fork && !defined __NR_clone +#if !defined __ARCH_USE_MMU__ || (!defined __NR_fork && !defined __NR_clone) make_stub(fork) #endif
-- 2.42.0
devel mailing list -- devel@uclibc-ng.org To unsubscribe send an email to devel-leave@uclibc-ng.org