socket_wrapper is currently completely broken on GNU/kFreeBSD. This is because the libc SONAME is "lib.so.0.1", but swrap_load_lib_handle() only checks for "libc.so.<N>". Perhaps swrap_load_lib_handle() should return RTLD_NEXT on systems that have it?
Other systems that are likely to be affected: * GNU/Hurd ("libc.so.0.3") * Linux on Alpha ("libc.so.6.1") * Linux on IA64 ("libc.so.6.1")
Thanks for your bug report. Here is a fix which should resolve the problem. http://git.cryptomilk.org/projects/socket_wrapper.git/log/?h=fix
It turns out it's not that simple. glibc defines RTLD_NEXT only if _GNU_SOURCE is defined. But when I tried recompiling socket_wrapper with -D_GNU_SOURCE=1, the build failed: cd /home/jwilk/socket_wrapper/obj/src && /usr/bin/cc -Dsocket_wrapper_EXPORTS -D_GNU_SOURCE=1 -std=gnu99 -pedantic -pedantic-errors -Wall -Wextra -Wshadow -Wmissing-prototypes -Wdeclaration-after-statement -Wunused -Wfloat-equal -Wpointer-arith -Wwrite-strings -Wformat-security -Wmissing-format-attribute -fPIC -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -I/home/jwilk/socket_wrapper/obj/src -I/home/jwilk/socket_wrapper/src -I/home/jwilk/socket_wrapper/obj -o CMakeFiles/socket_wrapper.dir/socket_wrapper.c.o -c /home/jwilk/socket_wrapper/src/socket_wrapper.c /home/jwilk/socket_wrapper/src/socket_wrapper.c:2389:1: error: function types not truly compatible in ISO C [-Wpedantic] { ^ /home/jwilk/socket_wrapper/src/socket_wrapper.c:2389:1: error: function types not truly compatible in ISO C [-Wpedantic] /home/jwilk/socket_wrapper/src/socket_wrapper.c:2588:1: error: function types not truly compatible in ISO C [-Wpedantic] { ^ /home/jwilk/socket_wrapper/src/socket_wrapper.c:2588:1: error: function types not truly compatible in ISO C [-Wpedantic] /home/jwilk/socket_wrapper/src/socket_wrapper.c:2629:1: error: function types not truly compatible in ISO C [-Wpedantic] { ^ /home/jwilk/socket_wrapper/src/socket_wrapper.c:2629:1: error: function types not truly compatible in ISO C [-Wpedantic] /home/jwilk/socket_wrapper/src/socket_wrapper.c:2718:1: error: function types not truly compatible in ISO C [-Wpedantic] { ^ /home/jwilk/socket_wrapper/src/socket_wrapper.c:2718:1: error: function types not truly compatible in ISO C [-Wpedantic] /home/jwilk/socket_wrapper/src/socket_wrapper.c:2745:1: error: function types not truly compatible in ISO C [-Wpedantic] { ^ /home/jwilk/socket_wrapper/src/socket_wrapper.c:2745:1: error: function types not truly compatible in ISO C [-Wpedantic] /home/jwilk/socket_wrapper/src/socket_wrapper.c:3357:1: error: function types not truly compatible in ISO C [-Wpedantic] { ^ /home/jwilk/socket_wrapper/src/socket_wrapper.c:3357:1: error: function types not truly compatible in ISO C [-Wpedantic] /home/jwilk/socket_wrapper/src/socket_wrapper.c:3444:1: error: function types not truly compatible in ISO C [-Wpedantic] { ^ /home/jwilk/socket_wrapper/src/socket_wrapper.c:3444:1: error: function types not truly compatible in ISO C [-Wpedantic] make[2]: *** [src/CMakeFiles/socket_wrapper.dir/socket_wrapper.c.o] Error 1
Yes, socket_wrapper isn't working with -D_GNU_SOURCE=1 yet. The function prototypes are different. Someone needs to look into this. I don't have time right now. So you have to wait or send a patch :)
I've opened https://bugzilla.samba.org/show_bug.cgi?id=10588 for _GNU_SOURCE=1
"You are not authorized to access bug #10588." I think the simplest way to fix this is to move swrap_load_lib_handle() (and maybe related functions to a separate C file, and build that one file with _GNU_SOURCE defined. Would that be acceptable approach? I am happy to implement it, once it wrap my head around how cmake works. :-)
I would prefer to fix it correctly and match the functions with the headers. http://git.cryptomilk.org/projects/socket_wrapper.git/commit/?h=gnu_source&id=c1c7f37a982876b11e0594366beb95a64653fdea
(In reply to comment #7) > http://git.cryptomilk.org/projects/socket_wrapper.git/commit/?h=gnu_source&id=c1c7f37a982876b11e0594366beb95a64653fdea I have tested the above patch on top of socket_wrapper 1.0.2, and I get the same failure as reported in comment 3. GNU libc provides a header with defines of the SONAMEs of the libraries which are part of it. Making use it of, it is possible to shorten (and do it correctly the first time) the loading of libc. Here there are the results I had with the attached patch that makes use of gnu/lib-names.h: ======= GNU/kFreeBSD (on VM): $ ctest Test project BUILDDIR Start 1: test_ioctl 1/9 Test #1: test_ioctl ....................... Passed 0.17 sec Start 2: test_echo_tcp_connect 2/9 Test #2: test_echo_tcp_connect ............ Passed 2.29 sec Start 3: test_echo_tcp_socket_options 3/9 Test #3: test_echo_tcp_socket_options ..... Passed 1.26 sec Start 4: test_echo_tcp_write_read 4/9 Test #4: test_echo_tcp_write_read ......... Passed 2.50 sec Start 5: test_echo_tcp_writev_readv 5/9 Test #5: test_echo_tcp_writev_readv ....... Passed 2.40 sec Start 6: test_echo_udp_sendto_recvfrom 6/9 Test #6: test_echo_udp_sendto_recvfrom .... Passed 2.35 sec Start 7: test_echo_udp_send_recv 7/9 Test #7: test_echo_udp_send_recv .......... Passed 2.35 sec Start 8: test_echo_udp_sendmsg_recvmsg 8/9 Test #8: test_echo_udp_sendmsg_recvmsg .... Passed 2.50 sec Start 9: test_sendmsg_recvmsg_fd 9/9 Test #9: test_sendmsg_recvmsg_fd .......... Passed 0.06 sec 100% tests passed, 0 tests failed out of 9 Total Test time (real) = 16.05 sec ======= GNU/Hurd (on VM): $ ctest --timeout 60 Test project BUILDDIR Start 1: test_ioctl 1/9 Test #1: test_ioctl .......................***Failed 0.05 sec Start 2: test_echo_tcp_connect 2/9 Test #2: test_echo_tcp_connect ............ Passed 2.09 sec Start 3: test_echo_tcp_socket_options 3/9 Test #3: test_echo_tcp_socket_options .....***Failed 1.07 sec Start 4: test_echo_tcp_write_read 4/9 Test #4: test_echo_tcp_write_read .........***Failed 2.10 sec Start 5: test_echo_tcp_writev_readv 5/9 Test #5: test_echo_tcp_writev_readv .......***Failed 2.10 sec Start 6: test_echo_udp_sendto_recvfrom 6/9 Test #6: test_echo_udp_sendto_recvfrom ....***Timeout 60.04 sec Start 7: test_echo_udp_send_recv 7/9 Test #7: test_echo_udp_send_recv ..........***Timeout 60.04 sec Start 8: test_echo_udp_sendmsg_recvmsg 8/9 Test #8: test_echo_udp_sendmsg_recvmsg ....***Timeout 60.04 sec Start 9: test_sendmsg_recvmsg_fd 9/9 Test #9: test_sendmsg_recvmsg_fd .......... Passed 0.02 sec 22% tests passed, 7 tests failed out of 9 Total Test time (real) = 187.72 sec The following tests FAILED: 1 - test_ioctl (Failed) 3 - test_echo_tcp_socket_options (Failed) 4 - test_echo_tcp_write_read (Failed) 5 - test_echo_tcp_writev_readv (Failed) 6 - test_echo_udp_sendto_recvfrom (Timeout) 7 - test_echo_udp_send_recv (Timeout) 8 - test_echo_udp_sendmsg_recvmsg (Timeout) Errors while running CTest (I had to specify a lower timeout, otherwise the default timeout is like 30 minutes. Most probably the failures are Hurd-specific, and I have not investigated them yet.) My suggestion is to not use _GNU_SOURCE for now, and instead use LIBC_SO on GNU libc.
Created attachment 9923 [details] Use LIBC_SO on GNU libc
I'm fine with this patch. Can you create a git-format-patch? Instead of +#ifdef __GLIBC__ +#include <gnu/lib-names.h> +#endif I would like to see a configure check for the header so we get HAVE_GNU_LIB_NAMES_H in config.h and include it if we found it. The patch is also needed for nss_wrapper and uid_wrapper.
(In reply to comment #10) > I'm fine with this patch. Can you create a git-format-patch? Sure. > Instead of > > +#ifdef __GLIBC__ > +#include <gnu/lib-names.h> > +#endif > > I would like to see a configure check for the header so we get > HAVE_GNU_LIB_NAMES_H in config.h and include it if we found it. OK. > The patch is also needed for nss_wrapper and uid_wrapper. Will do them once this is ACKed (so I don't have to eventually do fixes to three patches at the same time).
Created attachment 9924 [details] Use LIBC_SO from GNU libc, if available
Pino, I've pushed your patch upstream. Could you port it to nss_wrapper and uid_wrapper too? Thanks!
(In reply to comment #12) > Created attachment 9924 [details] > Use LIBC_SO from GNU libc, if available I apoligize, there is a small regression, i.e. the handle is no more cached. (Checking twice sometimes might now be enough...) New fix-for-the-fix coming ASAP.
Created attachment 9925 [details] always cache the libc handle
I've pushed it to master.
Created attachment 9996 [details] nss_wrapper: use LIBC_SO and LIBNSL_SO Try to use LIBC_SO and LIBNSL_SO when using GNU libc; nss_wrapper version.
Created attachment 9997 [details] uid_wrapper: use LIBC_SO Try to use LIBC_SO when using GNU libc; uid_wrapper version.
(In reply to comment #16) > I've pushed it to master. Thanks! As I promised, I'm providing now the (fixed ;) ) patches for LIBC_SO also for nss_wrapper and uid_wrapper.