1030692 - Make compiling nspr on windows possible again.

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P1)

Description

[Hannes Verschore [:h4writer]]

Since bug 942207 landed I cannot build nspr anymore on windows using MozillaBuild 1.9.0 with start-shell-msvc2012.bat. I get link errors:

$ cd mozilla-central/nsprpub
$ mkdir build-test
$ cd build-test
$ ../configure
$ make

gives:

> rm -f libnspr4.dll
> link -nologo -DLL -SUBSYSTEM:WINDOWS -DYNAMICBASE -OUT:"libnspr4.dll" -DEBUG -MA
> P   advapi32.lib ws2_32.lib winmm.lib ./prvrsion.obj io/./prfdcach.obj io/./prmw
> ait.obj io/./prmapopt.obj io/./priometh.obj io/./pripv6.obj io/./prlayer.obj io/
> ./prlog.obj io/./prmmap.obj io/./prpolevt.obj io/./prprf.obj io/./prscanf.obj io
> /./prstdio.obj threads/./prcmon.obj threads/./prrwlock.obj threads/./prtpd.obj l
> inking/./prlink.obj malloc/./prmalloc.obj malloc/./prmem.obj md/./prosdep.obj me
> mory/./prshm.obj memory/./prshma.obj memory/./prseg.obj misc/./pralarm.obj misc/
> ./pratom.obj misc/./prcountr.obj misc/./prdtoa.obj misc/./prenv.obj misc/./prerr
> .obj misc/./prerror.obj misc/./prerrortable.obj misc/./prinit.obj misc/./prinrva
> l.obj misc/./pripc.obj misc/./prlog2.obj misc/./prlong.obj misc/./prnetdb.obj mi
> sc/./praton.obj misc/./prolock.obj misc/./prrng.obj misc/./prsystem.obj misc/./p
> rthinfo.obj misc/./prtpool.obj misc/./prtrace.obj misc/./prtime.obj io/./prdir.o
> bj io/./prfile.obj io/./prio.obj io/./prsocket.obj misc/./pripcsem.obj threads/.
> /prcthr.obj threads/./prdump.obj threads/./prmon.obj threads/./prsem.obj threads
> /combined/./prucpu.obj threads/combined/./prucv.obj threads/combined/./prulock.o
> bj threads/combined/./prustack.obj threads/combined/./pruthr.obj md/windows/./nt
> misc.obj md/windows/./ntsec.obj md/windows/./ntsem.obj md/windows/./ntinrval.obj
>  md/windows/./ntgc.obj md/windows/./ntio.obj md/windows/./ntthread.obj md/window
> s/./ntdllmn.obj md/windows/./win32_errors.obj md/windows/./w32ipcsem.obj md/wind
> ows/./w32poll.obj md/windows/./w32rng.obj md/windows/./w32shm.obj  ./nspr.res
>    Creating library libnspr4.lib and object libnspr4.exp
> ntio.obj : error LNK2019: unresolved external symbol _TransmitFile@28 referenced
>  in function __PR_MD_SENDFILE
> ntio.obj : error LNK2019: unresolved external symbol _AcceptEx@32 referenced in
> function __PR_MD_FAST_ACCEPT
> ntio.obj : error LNK2019: unresolved external symbol _GetAcceptExSockaddrs@32 re
> ferenced in function __PR_MD_FAST_ACCEPT
> libnspr4.dll : fatal error LNK1120: 3 unresolved externals
> make[3]: *** [libnspr4.dll] Error 96
> make[3]: Leaving directory `/c/mozilla-source/mozilla-central/nsprpub/buidfail/p
> r/src'
> make[2]: *** [export] Error 2
> make[2]: Leaving directory `/c/mozilla-source/mozilla-central/nsprpub/buidfail/p
> r/src'
> make[1]: *** [export] Error 2
> make[1]: Leaving directory `/c/mozilla-source/mozilla-central/nsprpub/buidfail/p
> r'
> make: *** [export] Error 2

Comment 1

[Wan-Teh Chang]

Thank you for the bug report. This bug was introduced in the fix
for bug 50549. To work around this bug, you can undo this change
to mozilla-central/nsprpub/pr/src/Makefile.in:

https://hg.mozilla.org/projects/nspr/diff/3135013787c6/pr/src/Makefile.in

To fix this bug, we need to add mswsock.lib after ws2_32.lib in
mozilla-central/nsprpub/pr/src/Makefile.in.

By the way, you can check out the NSPR source code directly as
follows:

hg clone https://hg.mozilla.org/projects/nspr

Comment 2

[ssarangi]

This is still happening for me with the top of the trunk.
commit 32170ac2c3d24efaeb964ecfa6fa2d9653ba5c8b
Merge: c1415db 716f446
Author: Carsten "Tomcat" Book <[e-mail]>
Date:   Wed Dec 3 13:38:31 2014 +0100

    merge fx-team to mozilla-central a=merge

I am getting the same error as above. Using Visual Studio 2013. Has this been fixed?

Comment 3

[Sean Leonard]

Hey all, this is still happening with the tip:

4615:63b456dbbb94

Can this be fixed? It is manifesting itself in the NSS 3.17.4 distribution <https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_17_4_RTM/src/>, among other places.

Comment 4

[Ernie]

I found a StackOverload reference to the same unresolved symbol error, and it links to a couple SQLite files that incorporate a fix. Maybe the same would work for NSPR.

http://stackoverflow.com/questions/25192106/visual-studio-unresolved-symbol-interlockedcompareexchange

I couldn't figure out where to make the change or I'd have tried it. ;)

Comment 5

[Wan-Teh Chang]

Attachment: Patch: link with mswsock.lib

This patch implements the fix I proposed in comment 1: link with
mswsock.lib.

Strictly speaking, this fix is only needed by the "WINNT" build
configuration (OS_TARGET=WINNT) right now. For simplicity, I
omitted the test for OS_TARGET == WINNT. This will also allow the
"WIN95" build configuration to use those Microsoft Winsock extension
functions in the future.

Comment 6

[Wan-Teh Chang]

Attachment: Fix the static and import library names for the OS_TARGET=WINNT build configuration

The following two checkins to change the static and import library
names in MinGW builds broke the NSPR OS_TARGET=WINNT build configuration,
which uses the "lib" prefix in all library names. For example:
  Shared library (DLL): libnspr4.dll
  Import library:       libnspr4.lib
  Static library:       libnspr4_s.

Ideally we should remove the OS_TARGET=WINNT build configuration. Until
then, this patch will fix the build breakage. It is not very elegant due
to the limited ways to write conditional expressions in GNU Make.

Comment 7

[Wan-Teh Chang]

Comment on attachment 8625364 [details] [diff] [review]
Fix the static and import library names for the OS_TARGET=WINNT build configuration

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

::: config/rules.mk
@@ +79,5 @@
>  #
>  # Win95 and OS/2 require library names conforming to the 8.3 rule.
>  # other platforms do not.
>  #
>  ifeq (,$(filter-out WIN95 WINCE WINMO OS2,$(OS_TARGET)))

Note that OS_TARGET=WINNT is not on this list, so it will
be handled by the "else" branch that starts on line 93.

@@ +363,5 @@
>  
>  ifdef MOZ_PROFILE_GENERATE
>  # Clean up profiling data during PROFILE_GENERATE phase
>  export::
> +ifeq ($(NS_USE_GCC)_$(OS_ARCH),_WINNT)

This is an unrelated cleanup to concatenate $(NS_USE_GCC) and
$(OS_ARCH) in the common order used in this makefile.

Comment 8

[(not currently active) Ted Mielczarek]

Comment on attachment 8625364 [details] [diff] [review]
Fix the static and import library names for the OS_TARGET=WINNT build configuration

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

Thanks for the explanatory comments, that made review easy.

Comment 9

[(not currently active) Ted Mielczarek]

Presumably bug 814982 is really the better fix here, even if you don't want to go through the trouble of removing the WINNT code.

Comment 10

[Wan-Teh Chang]

Comment on attachment 8625360 [details] [diff] [review]
Patch: link with mswsock.lib

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

https://hg.mozilla.org/projects/nspr/rev/2f2498a5c87e

Comment 11

[Wan-Teh Chang]

Comment on attachment 8625364 [details] [diff] [review]
Fix the static and import library names for the OS_TARGET=WINNT build configuration

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

https://hg.mozilla.org/projects/nspr/rev/cf176edf81f2

Comment 12

[Wan-Teh Chang]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #9)
> Presumably bug 814982 is really the better fix here, even if you
> don't want to go through the trouble of removing the WINNT code.

Yes, having only one build configuration for Windows is the best
long-term solution. We may need to go through the intermediate
step of making OS_TARGET=WIN95 the default (and renaming it).