Similar to the issue mentioned in bug 1058778 my build with the beta branch (upcoming Firefox 45) using mingw-w64 fails with make[6]: Entering directory `/home/ubuntu/build/tor-browser/security/nss/cmd/shlibsign' i686-w64-mingw32-gcc -mwindows -o /home/ubuntu/build/tor-browser/obj-mingw/security/nss/cmd/shlibsign/shlibsign.exe -O2 -mwindows -mms-bitfields -Werror -DXP_PC -DSHLIB_SUFFIX=\"dll\" -DSHLIB_PREFIX=\"\" -UDEBUG -DNDEBUG -DWIN32 -D_WINDOWS -DWIN95 -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -I/home/ubuntu/build/tor-browser/obj-mingw/dist/include/nspr -I/home/ubuntu/build/tor-browser/obj-mingw/dist/include/nspr -I/home/ubuntu/build/tor-browser/obj-mingw/dist/include/nss -I/home/ubuntu/build/tor-browser/obj-mingw/dist/private/nss -mnop-fun-dllimport /home/ubuntu/build/tor-browser/obj-mingw/security/nss/cmd/shlibsign/shlibsign.o -specs=/home/ubuntu/build/msvcr100.spec -static -Wl,--enable-stdcall-fixup -Wl,--large-address-aware nss3.def /home/ubuntu/build/tor-browser/obj-mingw/dist/lib/libplc4.a /home/ubuntu/build/tor-browser/obj-mingw/dist/lib/libplds4.a /home/ubuntu/build/tor-browser/obj-mingw/dist/lib/libnspr4.a i686-w64-mingw32-gcc: error: nss3.def: No such file or directory make[6]: Entering directory `/home/ubuntu/build/tor-browser/security/nss/lib/softoken' /home/ubuntu/build/tor-browser/obj-mingw/config/nsinstall -t -m 664 /home/ubuntu/build/tor-browser/obj-mingw/security/nss/lib/softoken/libsoftokn.a /home/ubuntu/build/tor-browser/obj-mingw/dist/lib make[6]: *** [/home/ubuntu/build/tor-browser/obj-mingw/security/nss/cmd/shlibsign/shlibsign.exe] Error 1 It turns our that the fix for bug 856404 is causing the breakage. Backing this one out resolves the issue. There is a nss3.def in config/external/nss in my build dir, though. And rerunning |make nss3.def| does not change things.

I debugged this a bit and it turns out the error is due to export LDFLAGS="-specs=/home/ubuntu/build/msvcr100.spec" in our build script. I guess using a different spec file should not be the issue here. Rather, exporting LDFLAGS generally is probably causing this. I have not looked at it closer yet but does that make a bit sense at least?

Okay. I tested a bit more and verified that this happens in case LDFLAGS is exported (does not matter which value gets set). Jacek, I guess using LDFLAGS is still supposed to work after bug 856404 got fixed, right? If so, could you suggest a workaround which we could still squeeze into Tor Browser before we switch to ESR45? I'd rather not back out the fix for bug 856404.

Sorry for the delay. I can't reproduce it on the tip and I can't see what could break it. What's the difference in linker invocation if you don't export LDFLAGS?

Interesting. If I don't export LDFLAGS I get i686-w64-mingw32-gcc -mwindows -o /home/ubuntu/build/tor-browser/mozilla-mingw/security/nss/cmd/shlibsign/shlibsign.exe -O2 -mwindows -mms-bitfields -DXP_PC -DSHLIB_SUFFIX=\"dll\" -DSHLIB_PREFIX=\"\" -UDEBUG -DNDEBUG -DWIN32 -D_WINDOWS -DWIN95 -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -I/home/ubuntu/build/tor-browser/mozilla-mingw/dist/include/nspr -I/home/ubuntu/build/tor-browser/mozilla-mingw/dist/include/nspr -I/home/ubuntu/build/tor-browser/mozilla-mingw/dist/include/nss -I/home/ubuntu/build/tor-browser/mozilla-mingw/dist/private/nss -mnop-fun-dllimport /home/ubuntu/build/tor-browser/mozilla-mingw/security/nss/cmd/shlibsign/shlibsign.o /home/ubuntu/build/tor-browser/mozilla-mingw/dist/lib/libplc4.a /home/ubuntu/build/tor-browser/mozilla-mingw/dist/lib/libplds4.a /home/ubuntu/build/tor-browser/mozilla-mingw/dist/lib/libnspr4.a instead. No `-static -Wl,--enable-stdcall-fixup -Wl,--large-address-aware nss3.def`. I am trying to bisect a bit but it seems the ffvpx breakage is a major hassle here. :(

Okay, I am back in the bisecting business. It turned out my ffvpx issues were due to yasm being too old which seems to be bug 1260362. I got r283100 successfully built and there this bug is fixed. The only difference to ESR45 is the `nss.def` not being there anymore in the compile log. I'll track the change down as maybe other folks are hitting this issue as well and then we can close this bug as WORKSFORME.

Okay, the winner is rev 278034 (https://hg.mozilla.org/mozilla-central/rev/186450f22aab) which basically means bug 1235132 (with bug 1239672 as fixup). This is the first revision that works for me. This would mean either backporting bug 1235132 + dependencies (which looks like a bunch of changes) or backing out the fixes for bug 856404. Neither of those look particularly appealing to me. Mike, can you think of a third way for avoiding that build failure? If not, do you think backporting bug 1235132 and friends is without any bigger risks?

The question that would be worth answering is why did it work at all before? Because I see nothing before 186450f22aab that changed things significantly such that it would have broken you.

Yes, I agree with that. Alas, I won't have time anytime soon to look closer at that. I guess this means we can resolve this as WORKSFORME given that there is a workaround and it is fixed on mozilla-central for a while now. Thanks for your help.