1392513 - Build bustage on NSPR after Bug 1310197

Status: RESOLVED WORKSFORME

(NSPR :: NSPR, defect)

Description

[Mark Straver]

I've been trying to build our Mozilla browser fork with an updated NSPR 4.15 library, which causes build bustage as indicated in Bug 1310197 comment 44:

 1:05.31 w95sock.obj : error LNK2019: unresolved external symbol WSAIoctl referenced in function _pr_set_connectex
 1:05.31 nss3.dll : fatal error LNK1120: 1 unresolved externals

This is building on VS2013 with the Windows 8.1 SDK. The bustage occurs only on Windows 64-bit, which pointed me towards the patches in the related bug.
To be able to ship NSPR4.15 I've locally backed out the TFO patches in it, which resolved the build issue. Since we're not using TFO (yet) anyway, it's not a practical problem right now (why was this put in NSPR anyway instead of the network layer?) but clearly not something we can keep doing.

This is a blocker for current and future updates of NSPR in our product.

The cause seems to be that WSAIoctl is part of winsock2.h which isn't included; including that in w95sock causes other errors, so clearly not the correct solution.

Comment 1

[Mark Straver]

Setting needinfo to Dragana as suggested since she provided the patch in Bug 1310197.

Comment 2

[Dragana Damjanovic [:dragana]]

maybe you need to link with Ws2_32.lib

that is what docs say:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms741621(v=vs.85).aspx

Comment 3

[Mark Straver]

Considering this is a standalone lib (nss/nspr), shouldn't this kind of linking be determined by the code you supply, then? If it's a dependency for your code, it should be in your corner to make sure it links, so the lib can be included/used by other projects.

Comment 4

[Mark Straver]

As an aside, I see in the pr/src/Makefile.in that it should already be linked against ws2_32.lib:

OS_LIBS		= advapi32.lib ws2_32.lib mswsock.lib winmm.lib

So, how should this be resolved?

Comment 5

[Roy Tam]

(In reply to Mark Straver from comment #4)
> As an aside, I see in the pr/src/Makefile.in that it should already be
> linked against ws2_32.lib:
> 
> OS_LIBS		= advapi32.lib ws2_32.lib mswsock.lib winmm.lib
> 
> So, how should this be resolved?

Maybe adding pragma block in w95sock.c?

 #include "primpl.h"

+#if defined(_WIN64)
+#if defined(_MSC_VER)
+#pragma comment(lib, "ws2_32.lib")
+#endif
+#endif
 
 #define READ_FD     1
 #define WRITE_FD    2
 #define CONNECT_FD  3

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:KaiE, could you have a look please?

For more information, please visit BugBot documentation.

Comment 8

[Kai Engert [:KaiE:]]

Is this still an issue?

As I understand it, this doesn't apply to latest NSPR/Firefox code, but rather when using an older snapshot?

Did you try the suggestion from comment 5?

Comment 9

[Mark Straver]

We've worked around it in the past and it's currently (3 years later) no longer an issue or applicable as our platform has evolved significantly (we're on 4.35 atm).
Pretty sure this can be closed as "Worksforme" or something similar.

Comment 10

[Kai Engert [:KaiE:]]

Thanks Mark for reporting back!