[Bug 4195] accept4() declared when not implemented in some conditions

bugzilla at busybox.net bugzilla at busybox.net
Sat Sep 17 13:33:00 UTC 2011


https://bugs.busybox.net/show_bug.cgi?id=4195

--- Comment #3 from Guillaume Emont <guijemont at igalia.com>  ---
(In reply to comment #2)
> Comment on attachment 3565 [details]
> Only declare accept4() if __ASSUME_ACCEPT4 is defined
> 
> this is not what the ASSUME define is for.  it's an internal define so that
> uClibc itself can assume the kernel supports the function.  it has no bearing
> on the external API.

Ok, I did not understand that.

But then, what would be a clean way of fixing this issue? Do we want to always
have accept4() exposed? In that case, there should always be an implementation
available? Is that what libc/sysdeps/linux/common/stubs.c is for? I would guess
that the stub for accept4() should be made when neither __NR_accept4 nor
__NR_socketcall are defined, regardless of the value of __UCLIBC_HAS_SOCKET__.

Also, there's a simple way to reproduce the issue without Qt: the attached
accept4_test.c file compiles but does not link:

$ arm-linux-gcc accept4_test.c -o accept4_test
/tmp/ccOdyyKr.o: In function `main':
accept4_test.c:(.text+0x28): undefined reference to `accept4'
collect2: ld returned 1 exit status

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the uClibc-cvs mailing list