mingw-w64 build fails with "nss3.def: No such file or directory" if LDFLAGS get set

RESOLVED WORKSFORME

Status

Firefox Build System
General
RESOLVED WORKSFORME
2 years ago
4 months ago

People

(Reporter: Georg Koppen, Unassigned)

Tracking

45 Branch
All
Windows

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
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.
(Reporter)

Comment 1

2 years ago
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?
(Reporter)

Comment 2

2 years ago
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.
Flags: needinfo?(jacek)
Summary: mingw-w64 build fails with "nss3.def: No such file or directory" → mingw-w64 build fails with "nss3.def: No such file or directory" if LDFLAGS get set

Comment 3

2 years ago
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?
Flags: needinfo?(jacek)
(Reporter)

Comment 4

2 years ago
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. :(
(Reporter)

Comment 5

2 years ago
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.
(Reporter)

Comment 6

2 years ago
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?
Flags: needinfo?(mh+mozilla)
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.
Flags: needinfo?(mh+mozilla)
(Reporter)

Comment 8

2 years ago
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.
(Reporter)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME

Updated

4 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.