Opened 5 years ago

Last modified 5 years ago

#15562 confirmed defect

Use ws2_32.dll (Winsock 2) instead of the ancient wsock32.dll (Winsock 1.1)

Reported by: justinian Owned by:
Priority: normal Milestone: 3.2.0
Component: wxMSW Version: stable-latest
Keywords: winsock winsock2 pragma linking Cc:
Blocked By: Blocking:
Patch: yes


I've been encountering a problem when using wxWidgets-2.9.5 with boost::asio (or, conceivably, other networking libraries) when relying on calls that differ between winsock 1.1 and winsock 2. (setsockopt with IP_TTL is an example.)

The problem exists even if I exclude networking classes from wx with wxNO_NET_LIB, or wxUSE_SOCKETS=0, have the correct header order and/or never include a wx header that includes <winsock.h>.

The problem is that source:wxWidgets/trunk/include/msvc/wx/setup.h contains the line:

#pragma comment(lib, "wsock32")

This causes the winsock 1.1 libraries to be linked, and so calls made to matching functions from winsock 2 link against the wrong functions.

My basic fix for this is to just move the pragma inside the existing ifdef block for wxNO_NET_LIB, which I've attached a simple patch for. Ideally, I'd love to see wx switch to winsock 2 in general as well (winsock 1.1 is 17 years old on the desktop, 10 years old on WinCE..), but I understand that means changing includes and re-testing all the existing classes for compatibility.

Also, I've seen other winsock-related issues here (In particular #10931), which relate to header inclusion order get closed as invalid. Please note that this issue is linking-related, not windows header related.

Attachments (1)

pragma_lib_wsock32_under_wxNO_NET_LIB.patch download (1.4 KB) - added by justinian 5 years ago.
Patch to move pragma lib inside wxNO_NET_LIB ifdef block

Download all attachments as: .zip

Change History (8)

Changed 5 years ago by justinian

Patch to move pragma lib inside wxNO_NET_LIB ifdef block

comment:1 Changed 5 years ago by justinian

(Correction: I meant to say winsock 2 is 17 years old. Winsock 1.1 is far older.)

comment:2 Changed 5 years ago by vadz

  • Milestone set to 3.0
  • Status changed from new to confirmed

I think using WinSock 2 is actually safe in this file because it's only used with MSVC, but I'm indeed not sure about doing it in build/bakefiles/common.bkl as that would affect all compilers and who knows if some ancient MinGW version has ws2_32.lib import library. And if we change it here but not there, it would be inconsistent and could result in even more weird problems...

OTOH I just checked and MinGW 3.4.5 (the oldest version I still have) does have ws2_32.lib. So maybe it is safe to use it?

Any opinions for/against?

If we do take the risk to change it, the attached patch should be replaced with

  • include/msvc/wx/setup.h

    diff --git a/include/msvc/wx/setup.h b/include/msvc/wx/setup.h
    index 31c5efc..dc165c4 100644
    a b  
    235235    #pragma comment(lib, "uuid")
    236236    #pragma comment(lib, "rpcrt4")
    237237    #pragma comment(lib, "advapi32")
    238     #pragma comment(lib, "wsock32")
     238    #pragma comment(lib, "ws2_32")
    239239    #if wxUSE_URL_NATIVE
    240240        #pragma comment(lib, "wininet")
    241241    #endif

If we do not, then the attached patch should be applied for 3.0 and the change above done for 3.2.

comment:3 Changed 5 years ago by justinian

I'd still be wary of putting pragmas for either wsock32 or ws2_32 outside of the wxNO_NET_LIB (or some other define) block. If someone is intentionally linking wsock32 and including the appropriate headers, they may run into the reverse of the issue I was having.

comment:4 Changed 5 years ago by vadz

This is a good point. But it would still be better to use ws2_32 by default to make things just work out of the box with asio, I wonder how long did it take you to determine that linking with wsock32 was the cause of the problems you were seeing (sorry about this...).

comment:5 Changed 5 years ago by justinian

Oh I certainly agree that ws2_32 should be the default, though the other necessary source code changes might be slightly more difficult than replacing all winsock.h with winsock2.h. (I don't have much experience with the wx net library, so perhaps it is that easy..)

Fortunately, I had a working non-wx cli version of my code, so once I narrowed the problem down to just my wx-based tool, it was mostly a matter of header spelunking. :)

comment:6 Changed 5 years ago by vadz

  • Milestone changed from 3.0 to 3.2
  • Summary changed from Auto-linking wsock32 (Winsock 1.1) on MSW causes problems to Use ws2_32.dll (Winsock 2) instead of the ancient wsock32.dll (Winsock 1.1)

OK, let's just do the minimal change for now and switch to Winsock 2 for 3.2.

comment:7 Changed 5 years ago by VZ

(In [75002]) Only auto-link wsock32.dll if net library is used.

Otherwise linking with it can create problems with the code using other
network libraries, which link with ws2_32.dll (Winsock 2).

See #15562.

Note: See TracTickets for help on using tickets.