Trunk builds failing on shlibsign.exe

[RyanVM]

Hey guys, a few weeks ago I went on vacation(September 10-17) and when I got home, my builds have constantly failed at the same point when trying to build shlibsign.exe. I've tried completely killing my entire source tree and re-pulling from CVS but to no avail. I can't figure out how things would stop working when nothing changed on my system (literally, before I left for vacation, things built fine. I get home, and they don't anymore). For the record, I'm using make 3.80.

Code: Select all

make[5]: *** No rule to make target `d:/mozilla/mozilla/foxbuild/dist/lib/smime3.lib', needed by `d:/mozilla/mozilla/foxbuild/nss/shlibsign.exe'.  Stop.
make[5]: Leaving directory `/cygdrive/d/mozilla/mozilla/security/nss/cmd/shlibsign'

I've tried asking in #developers, but nobody seems to have any ideas. If you guys have any clue, I'd love to hear it!

[RyanVM]

Here's some more info which may help. I was able to isolate some more errors leading up to the failure.

Code: Select all

make[7]: *** [d:/mozilla/mozilla/foxbuild/nss/freebl/WIN95_SINGLE_SHLIB/freebl3. dll] Error 157
make[6]: *** [libs] Error 2
make[6]: *** [d:/mozilla/mozilla/foxbuild/nss/softokn/softokn3.dll] Error 157
make[6]: *** [d:/mozilla/mozilla/foxbuild/nss/nss/nss3.dll] Error 157
make[6]: *** [d:/mozilla/mozilla/foxbuild/nss/ssl/ssl3.dll] Error 157
make[6]: *** [d:/mozilla/mozilla/foxbuild/nss/smime/smime3.dll] Error 157
make[7]: *** [d:/mozilla/mozilla/foxbuild/nss/nssckbi/nssckbi.dll] Error 157
make[5]: *** No rule to make target `d:/mozilla/mozilla/foxbuild/dist/lib/smime3.lib', needed by `d:/mozilla/mozilla/foxbuild/nss/shlibsign.exe'.  Stop.
make[4]: *** [libs] Error 2
make[3]: *** [libs_tier_toolkit] Error 2
make[2]: *** [tier_toolkit] Error 2
make[1]: *** [default] Error 2
make: *** [build] Error 2

Also, I've noticed some of the following errors as well:

Code: Select all

LINK : fatal error LNK1181: cannot open input file 'link.obj'

[tqft]

Did re-pulling the source tree include fresh config and client.mk files?

You have tried make -f client.mk clean? Fresh files won't help if they aren't being compiled.

About that time something went screwy for my builds (make ... clean didn't help) and I made sure - deleted the config files (including in the config dir), client.mk after I did make -f client.mk clean, then updated from CVS and then built.

[RyanVM]

Did re-pulling the source tree include fresh config and client.mk files?

You have tried make -f client.mk clean? Fresh files won't help if they aren't being compiled.

About that time something went screwy for my builds (make ... clean didn't help) and I made sure - deleted the config files (including in the config dir), client.mk after I did make -f client.mk clean, then updated from CVS and then built.

I completely nuked my entire build directory and objdir, so yes. I've also tried building on another computer and ran into the same problem...

[RyanVM]

Man, I just don't get this. I did an install of XP SP2 and VS2005 in VirtualPC and setup a brand new build environment following the directions at the Mozilla Developer Center to the letter. I even created a brand new .mozconfig using the build configurator. Now I'm getting this error:

Code: Select all

LINK : fatal error LNK1181: cannot open input file 'link.obj'
make[7]: *** [c:/mozbuild/mozilla/objdir/nss/freebl/WIN95_SINGLE_SHLIB/freebl3.dll] Error 157

Favor request: would somebody with a working VS2005 Trunk build environment be willing to send me their entire cygwin directory? I'm beginning to suspect some updated cygwin component is the culprit.

[NeilRashbrook]

Now I'm getting this error:

Code: Select all

LINK : fatal error LNK1181: cannot open input file 'link.obj'
make[7]: *** [c:/mozbuild/mozilla/objdir/nss/freebl/WIN95_SINGLE_SHLIB/freebl3.dll] Error 157

Both Mook and I have seen this when cross-compiling Mozilla; Mook uses wine to invoke LINK while I use SFU which can run LINK natively. Now unlike the rest of the tree, the NSS build system uses the variable LINK to specify the linker used when building for Windows. To cross-compile we therefore need to override the variable so that we can use the Windows linker rather than the native linker. Unfortunately LINK uses the variable LINK to specify additional command-line parameters. Thus when NSS tries to $(LINK) <link>, LINK actually sees LINK LINK <link> and fails to find link.obj with the error as you have observed.