Closed dmik closed 3 years ago
Note that LIBC socketpair
(a wrapper around TCP/IP socketpair
) is not a LIBC export. Instead, it lives in a static library libsocket
as well as libc_dll
so that it's linked to any app using LIBC. Just for the record. I have no idea why it was done this way but it basically means that the wrapper code is duplicated in any EXE and it will have to be recompiled in order to incorporate the fix. Simply replacing the LIBC DLL won/t help.
Back in the EMX days, you had to link with -lsocket for any network code. kLIBC removed the need to link with it and I thought it was more of a wrapper now. I assume that EMX did it that way due to where ever they got their libc code from. Solaris for example still uses -lsocket I believe.
Yes, I even remember that. Not needed in case of kLIBC because, as I mentioned, libsocket
stuff is now part of libc_dll
(which is dragged in by gcc
by default unless -nostdlib
is given). My guess is that Knut left it as statics in order to be able to use the same kLIBC DLL with different TCP/IP stacks by just changing libsocket
in question. However, from what I see now, the build of kLIBC for older TCP/IP includes libc_dll
as well which means you will get other versions by just linking that... From this POV, having this stuff as static is just a waste of code segment space.
I can observe in bitwiseworks/qtwebengine-chromium-os2#12 that calling
socketpair
(bylibevent
, to implement a socket based event pump) sometimes fails with ENOTSOCK for no reason. This error code comes to LIBC directly from thesocketpair
implementation in the OS/2 TCP/IP stack (TCPIP32.DLL) and LIBC simply passes it over to the caller. This expectedly breaks normal Chromium execution because it can't live w/o a socket channel.Practice shows that simply retrying the
socketpair
call in such a case cures it. (Which makes this hack similar to what we do for OS/2 TCP/IPselect
and EBADF/EFAULT, see bitwiseworks/libcx#85). We should incorporate such a retrial into the LIBCsocketpair
implementation.