| Summary: | accept4() declared when not implemented in some conditions | ||
|---|---|---|---|
| Product: | uClibc | Reporter: | Guillaume Emont <guijemont> |
| Component: | Networking | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | rep.dot.nop, uclibc-cvs |
| Priority: | P5 | ||
| Version: | 0.9.32 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: |
Only declare accept4() if __ASSUME_ACCEPT4 is defined
define __ASSUME_ACCEPT4 for arm kernels >= 2.6.36 Simplistic program using accept4(). Compiles but does not link with uClibC 0.9.32 + arm kernel 2.6.35 Make accept4() stub if accept4 syscall is not available even if socket APIs are made available stripping "&& !defined __UCLIBC_HAS_SOCKET__" from conditions in stubs.c |
||
Created attachment 3571 [details]
define __ASSUME_ACCEPT4 for arm kernels >= 2.6.36
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.
(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 Created attachment 3595 [details]
Simplistic program using accept4(). Compiles but does not link with uClibC 0.9.32 + arm kernel 2.6.35
Created attachment 3601 [details]
Make accept4() stub if accept4 syscall is not available even if socket APIs are made available
This patch seems like a much cleaner fix, and it does work for me.
I suspect the other "!defined __UCLIBC_HAS_SOCKET__" occurences should be removed as well: keeping them make the __NR_* conditions redundant (these are undefined if __UCLIBC_HAS_SOCKET__ is not defined), and it does not look like the right logic.
Comment on attachment 3601 [details]
Make accept4() stub if accept4 syscall is not available even if socket APIs are made available
stripping "!defined __UCLIBC_HAS_SOCKET__" from all the lines in stubs.c makes sense to me. maybe Bernhard can speak to what he was going for exactly with those.
Created attachment 3607 [details]
stripping "&& !defined __UCLIBC_HAS_SOCKET__" from conditions in stubs.c
Here's the patch that removes the condition for all the socket stubs.
Any update on that? Can Bernhard comment on it? I will have a lokk when I am back from ELC-E. (In reply to comment #9) > I will have a lokk when I am back from ELC-E. Brilliant! I can pay you a Czech beer to thank you in advance as I am here too. should be fixed in 5724141a037edb06c15bd78cfe04108e36991276 |
Created attachment 3565 [details] Only declare accept4() if __ASSUME_ACCEPT4 is defined When compiling for arm against a 2.6.35 kernel, I have the following inconsistency: - sys/sockets.h declares accept4() - accept4() is not implemented, because neither __NR_accept4 nor __NR_socketcall is defined When trying to compile Qt against uClibC 0.9.32 in these conditions, I get a linking error complaining that accept4() is not available. If I comment out the declaration of accept4() in sys/sockets.h, Qt compiles without complaining. I'm not sure I understand everything that happens there though. All of this occurs inside of buildroot. I have patches that seem to fix this, but I am not sure that is the right way of doing this. Might be related to #3877