[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