323645 - unable to build with MSYS/msvc on Windows since 2006-01-13 (after bug 317620 landed)

Status: VERIFIED DUPLICATE of bug 317620

(Firefox Build System :: General, defect)

Description

[Mike Connor [:mconnor]]

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'

Comment 1

[Mike Connor [:mconnor]]

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

Comment 2

[cls]

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.

Comment 3

[Mike Connor [:mconnor]]

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.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

(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)

Comment 5

[cls]

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 ?

Comment 6

[Wan-Teh Chang]

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.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Attachment: autoconf.mk

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

Comment 8

[Wan-Teh Chang]

Attachment: Use MOZ_BUILD_ROOT to define ABS_DIST

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"

Comment 9

[:Gavin Sharp [email: [e-mail]]]

(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!

Comment 10

[cls]

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

Comment 11

[:Gavin Sharp [email: [e-mail]]]

(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"?

Comment 12

[cls]

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.

Comment 13

[Wan-Teh Chang]

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 ***

Comment 14

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 16

[cls]

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.)  

Comment 17

[Wan-Teh Chang]

Attachment: Set ABS_DIST to win32 path for msys (also attached to bug 317620)

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