Attempting to build trunk Windows debug fails since the new NSS version landed last week, short version of the error (slightly varies on vc6's linker, but similar error text) Tested configurations: vc71 + msys vc6 + msys vc6 + cygwin rc.exe -DSHLIB_SUFFIX=\"dll\" -DSHLIB_PREFIX=\"\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -DDEBUG -D_DEBUG -DDEBUG_Gavin -DWIN32 -D_WINDOWS -D_X86_ -DWIN95 -DMP_ASSEMBLY_MULTIPLY -DMP_ASSEMBLY_SQUARE -DMP_ASSEMBLY_DIV_2DX1D -DMP_USE_UINT_DIGIT -DMP_NO_MP_WORD -DMP_API_COMPATIBLE -I/moz/mozilla/ff/dist/include/nspr -I/moz/mozilla/ff/dist/include -IC:/moz-debug/mozilla/ff/dist/public/nss -IC:/moz-debug/mozilla/ff/dist/private/nss -IC:/moz-debug/mozilla/ff/dist/include -I/moz/mozilla/ff/dist/include/dbm -Impi -Iecl -FoC:/moz-debug/mozilla/ff/nss/freebl/WIN95_SINGLE_SHLIB/freebl.res freebl.rc C:/moz-debug/mozilla/ff/nss/freebl/WIN95_SINGLE_SHLIB/freebl.res finished cp freebl.def C:/moz-debug/mozilla/ff/nss/freebl/WIN95_SINGLE_SHLIB/freebl.def rm -f C:/moz-debug/mozilla/ff/nss/freebl/WIN95_SINGLE_SHLIB/freebl3.dll link -nologo -DLL -SUBSYSTEM:WINDOWS -PDB:NONE -DEBUG -OUT:"C:/moz-debug/mozilla/ff/nss/freebl/WIN95_SINGLE_SHLIB/freebl3.dll" -DEF:C:/moz-debug/mozilla/ff/nss/freebl/WIN95_SINGLE_SHLIB/freebl.def -MAP C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\freeblver.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\ldvector.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\prng_fips1861.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\sysrand.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\sha_fast.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\md2.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\md5.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\sha512.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\alghmac.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\rawhash.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\alg2268.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\arcfour.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\arcfive.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\desblapi.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\des.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\rijndael.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\aeskeywrap.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\dh.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\ec.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\pqg.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\dsa.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\rsa.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\shvfy.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\tlsprfalg.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\mpprime.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\mpmontg.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\mplogic.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\mpi.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\mp_gf2m.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\mpcpucache.obj C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\mpi_x86.obj \\moz\\mozilla\\ff\\dist\\lib\\secutil.lib \\moz\\mozilla\\ff\\dist\\lib\\plc4.lib \\moz\\mozilla\\ff\\dist\\lib\\plds4.lib \\moz\\mozilla\\ff\\dist\\lib\\nspr4.lib C:\\moz-debug\\mozilla\\ff\\nss\\freebl\\WIN95_SINGLE_SHLIB\\freebl.res LINK : warning LNK4224: /PDB:NONE is no longer supported; ignored LINK : fatal error LNK1104: cannot open file '\moz\mozilla\ff\dist\lib\secutil.lib' make[7]: *** [C:/moz-debug/mozilla/ff/nss/freebl/WIN95_SINGLE_SHLIB/freebl3.dll] Error 80 make[7]: Leaving directory `/moz/mozilla/security/nss/lib/freebl'

This is a blocker for Windows developers who need access to a debug build.

It looks like you're doing a srcdir build in c:/moz-debug/mozilla but there are a lot of references to c:/moz/mozilla/ff/dist . It almost looks like you have DIST set in your environment to force the tree to use c:/moz/mozilla/ff/dist instead of the default. I don't see how those references would occur otherwise.

my .mozconfig is as follows (this has been working at least six months) . $topsrcdir/browser/config/mozconfig ac_add_options --enable-debug ac_add_options --disable-tests ac_add_options --enable-optimize mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objs mk_add_options MOZ_MAKE_FLAGS="-j4 -s" DIST isn't set in either my cygwin or msys environment.

(The log is actually mine, in case you're wondering about the objdir discrepancy: I'm using essentially the same .mozconfig, with MOZ_OBJDIR=@TOPSRCDIR@/ff)

Ok, in your debug tree, can you run: make -p -C security/manager ack and get the values for DIST, ABS_DIST, MOZ_BUILD_ROOT, NSPR_CFLAGS, NSPR_LIBS, NSPR_INCLUDE_DIR & NSPR_LIB_DIR ?

Please also attach the file C:\moz-debug\mozilla\ff\config\autoconf.mk to this bug report. cls: ABS_DIST is /moz/mozilla/ff/dist, and MOZ_BUILD_ROOT is C:/moz-debug/mozilla/ff. These two differ in more than the "dist" at the end of ABS_DIST. We may need to set ABS_DIST in mozilla/security/manager/Makefile.in in the same way we set MOZ_BUILD_ROOT in http://lxr.mozilla.org/seamonkey/source/configure.in#1686 (specifically, use "pwd -W" for MSYS), or just use $(MOZ_BUILD_ROOT)/dist (instead of $(ABS_DIST)) in mozilla/security/manager/Makefile.in.

Hmm, I just encountered the same issue building a non-debug build of Firefox with MSYS/MSVC7.1 on a different computer (standard mozconfig, with --disable-tests). Attached is C:\moz-debug\mozilla\ff\config\autoconf.mk from the original computer. I also ran: C:\moz-debug\mozilla\ff>make -p -C security/manager > tmp.log (there is no target "ack" in security/manager/Makefile...) and obtained from tmp.log: DIST=C:/moz-debug/mozilla/ff/dist MOZ_BUILD_ROOT = C:/moz-debug/mozilla/ff NSPR_CFLAGS = -I$(DIST)/include/nspr NSPR_LIBS = $(DIST)/lib/nspr4.lib $(DIST)/lib/plc4.lib $(DIST)/lib/plds4.lib NSPR_LIB_DIR = $(DIST)/lib

If I understand the problem correctly, whether the build is debug or optimized should not matter, and the problem should only occur with MSYS, not with Cygwin. Since the original bug description mentions Cygwin, I am confused. Please try this patch. To save time, you can take the following shortcut: 1. cd into security/manager in your build tree (as opposed to the source tree). 2. say "make realclean clobber_all" 3. apply this patch to "Makefile". 4. say "make"

(In reply to comment #8) > If I understand the problem correctly, whether the build > is debug or optimized should not matter, and the problem > should only occur with MSYS, not with Cygwin. Since the > original bug description mentions Cygwin, I am confused. I've not tried building with Cygwin lately, maybe Mike can provide more details. > Please try this patch. To save time, you can take the > following shortcut: This patch does indeed solve the issue for me. Thank you for looking into this!

Gavin: you didn't print the value of ABS_DIST, which is key. WTC: There's more going on here than a simple msys vs cygwin issue. My normal msys objdir build, invoking configure by hand from outside of the mozilla srctree, works fine without your new patch. My msys objdir build that uses client.mk and has MOZ_OBJDIR=@TOPSRCDIR@/obj-ff works fine as well. If ABS_DIST is being set to /moz/mozilla/ff rather than /c/moz-debug/mozilla/ff (note the drive prefix), that probably means that a non-standard mount point is being used for the location of the mozilla tree and we've never supported that (see bug 211689). For my client.mk build, ABS_DIST := /c/root/mozilla/obj-ff/dist DIST = $(DEPTH)/dist MOZ_BUILD_ROOT = c:/root/mozilla/obj-ff NSPR_INCLUDE_DIR := /c/root/mozilla/obj-ff/dist/include/nspr

(In reply to comment #10) > Gavin: you didn't print the value of ABS_DIST, which is key. Sorry, yes. I see "ABS_DIST := /moz/mozilla/ff/dist" in tmp.log. I guess that means my build setup is "not supported"? I've been building this way for a while now, without problems. How would I ensure that I'm not using a "non-standard mount point"?

If you go to c:\full\path, run `pwd`, and the returned path doesn't contain a drive-prefix (ie, /c/full/path or /cygdrive/c/full/path), then it's an unsupported path. Unless you're building under c:\cygwin or c:\msys, this shouldn't be an issue unless you've manually added a mount point. Just running 'mount' should show you your list of mount points. Looking back at the original msys bug, the mount problem was fixed for msys, just not for cygwin. We should be able to easily fix this now that we know what the actual problem is.

I suggest that we mark this bug a duplicate of bug 317620 and attach the patches there. *** This bug has been marked as a duplicate of 317620 ***

(In reply to comment #12) > If you go to c:\full\path, run `pwd`, and the returned path doesn't contain a > drive-prefix (ie, /c/full/path or /cygdrive/c/full/path), then it's an > unsupported path. Unless you're building under c:\cygwin or c:\msys, this > shouldn't be an issue unless you've manually added a mount point. Just running > 'mount' should show you your list of mount points. Ah, hmm. I had an entry for C:\moz-debug pointing to /moz in my fstab file on the first computer (the one used to get the information in this bug), but I do not have that on the second computer where I was also seeing this problem ("mount" shows no mountpoints for the build directory there). The patch was tested on the second computer.

(In reply to comment #13) > I suggest that we mark this bug a duplicate of bug 317620 > and attach the patches there. I think it's usually easier to track issues like this if they are kept separate, and indicate the relationship via "depends" or "blocks"... people with this problem won't be looking for "land NSS 3.11" bugs.

I attached the patch to bug 317620. It took me awhile to reproduce the problem as it doesn't seem to occur with gcc at all. I beginning to think that msys is auto-translating args to gcc since /mingw/bin/gcc is on a special mount point. (I wonder if we could do the same for msvc by requiring a special /msvc mount point.)

This is the patch by cls to fix the bug. I've checked it in on the Mozilla trunk (1.9 alpha). Checking in Makefile.in; /cvsroot/mozilla/security/manager/Makefile.in,v <-- Makefile.in new revision: 1.62; previous revision: 1.61 done