799076 - Unable to Build SeaMonkey (or Firefox) with VS2008SP1/VC9 since Bug 792188

Status: RESOLVED FIXED

(Core :: WebRTC: Signaling, defect)

Description

[Philip Chee]

Build failure Building with Visual Studio 2008SP1 (VC9)

c:/t1/hg/objdir-sm/mozilla/media/webrtc/signaling/signaling_sipcc/../../../../../../comm-central/mozilla/media/webrtc/signaling/src/sipcc/core/sipstack/ccsip_platform_tcp.c(524) : error C2065: 'EWOULDBLOCK' : undeclared identifier
c:/t1/hg/objdir-sm/mozilla/media/webrtc/signaling/signaling_sipcc/../../../../../../comm-central/mozilla/media/webrtc/signaling/src/sipcc/core/sipstack/ccsip_platform_tcp.c(524) : error C2065: 'EINPROGRESS' : undeclared identifier
c:/t1/hg/objdir-sm/mozilla/media/webrtc/signaling/signaling_sipcc/../../../../../../comm-central/mozilla/media/webrtc/signaling/src/sipcc/core/sipstack/ccsip_platform_tcp.c(858) : error C2065: 'EWOULDBLOCK' : undeclared identifier
c:/t1/hg/objdir-sm/mozilla/media/webrtc/signaling/signaling_sipcc/../../../../../../comm-central/mozilla/media/webrtc/signaling/src/sipcc/core/sipstack/ccsip_platform_tcp.c(860) : error C2065: 'ENOTCONN' : undeclared identifier
c:/t1/hg/objdir-sm/mozilla/media/webrtc/signaling/signaling_sipcc/../../../../../../comm-central/mozilla/media/webrtc/signaling/src/sipcc/core/sipstack/ccsip_platform_tcp.c(918) : error C2065: 'EWOULDBLOCK' : undeclared identifier
c:/t1/hg/objdir-sm/mozilla/media/webrtc/signaling/signaling_sipcc/../../../../../../comm-central/mozilla/media/webrtc/signaling/src/sipcc/core/sipstack/ccsip_platform_tcp.c(1079) : error C2065: 'EWOULDBLOCK' : undeclared identifier

Putting the following in /media/webrtc/signaling/src/sipcc/cpr/include/cpr_errno.h allows my build to continue.

#ifndef EWOULDBLOCK
#define EWOULDBLOCK             WSAEWOULDBLOCK
#endif
#ifndef EINPROGRESS
#define EINPROGRESS             WSAEINPROGRESS
#endif
#ifndef ENOTCONN
#define ENOTCONN                WSAENOTCONN
#endif

For some reason putting this in:
/media/webrtc/signaling/src/sipcc/cpr/win32/cpr_win_errno.c
didn't work.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Should work in cpr_win_errno.h...  The function in the .c file isn't actually used anywhere in the current code (and was mostly for printing debugs from comments in cpr_linux_errno.c

The right place is cpr_win_errno.h

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Add errno definitions for VC9 and below

Comment 3

[Bill Gianopoulos [:WG9s]]

Any possibility of getting this landed on m-c before the uplift?

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Can you run a quick test of it?

Comment 5

[Bill Gianopoulos [:WG9s]]

(In reply to Randell Jesup [:jesup] from comment #4)
> Can you run a quick test of it?

My Windows build was successful using VC9 after applying this patch.

Comment 6

[Timothy B. Terriberry (:derf)]

Comment on attachment 669128 [details] [diff] [review]
Add errno definitions for VC9 and below

Review of attachment 669128 [details] [diff] [review]:
-----------------------------------------------------------------

So, the issue here is that EINPROGRESS, etc., have numerical values of 1xx in MSVC 10, and this patch will give them 10xxx values under earlier compilers. This can't possibly work correctly, unless these are constants set and read solely by our own code (in which case they shouldn't be using system defines).

I'm r+'ing this on the understanding that the code that uses these defines is currently not called, and that this patch is just papering over the build problem. However, after landing, we need to either leave this bug open or file a follow-up bug on fixing this properly. Otherwise this is a landmine waiting to go off.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

http://hg.mozilla.org/mozilla-central/rev/4c95b705edb0

Comment 8

[Bill Gianopoulos [:WG9s]]

(In reply to Timothy B. Terriberry (:derf) from comment #6)
> Comment on attachment 669128 [details] [diff] [review]
> Add errno definitions for VC9 and below
> 
> Review of attachment 669128 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> So, the issue here is that EINPROGRESS, etc., have numerical values of 1xx
> in MSVC 10, and this patch will give them 10xxx values under earlier
> compilers. This can't possibly work correctly, unless these are constants
> set and read solely by our own code (in which case they shouldn't be using
> system defines).
> 
> I'm r+'ing this on the understanding that the code that uses these defines
> is currently not called, and that this patch is just papering over the build
> problem. However, after landing, we need to either leave this bug open or
> file a follow-up bug on fixing this properly. Otherwise this is a landmine
> waiting to go off.

Well this should be mitigated by the fact that we ship the DLL files for the appropriate libraries so if built with VC9 should have the VC9 versions etc.

I do notice that elsewhere in the code this uses cpr_errno.h and tests against CPR_EINPROGRESS etc.  Does doing that somehow normalize the codes so that this is not an issue?