Closed Bug 329209 Opened 19 years ago Closed 19 years ago

Cannot build with the free VC8 Express Edition

Categories

(Firefox Build System :: General, defect)

x86
Windows XP
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: rbs, Unassigned)

Details

I have followed the instructions to switch to VC8 express. But I have been unsuccessul to get my build back in shape. This is a blocker for me since I cannot do anything at all. (I did see bug 249782 -- but since it is too crowded, I am filing this specific bug to focus on the midl problem that I get.) Any helpful clues as to what I should do? Here is the output I get when trying the build the entire tree (suite). D:\Mozilla\tip\mozilla>make -f client.mk build Adding client.mk options from D:\Mozilla\tip\mozilla\mozconfig-suite: MOZ_OBJDIR=$(TOPSRCDIR)/../objs/suite MOZ_CO_PROJECT=suite make[1]: Entering directory `/cygdrive/d/Mozilla/tip/mozilla' cd /cygdrive/d/Mozilla/tip/mozilla/../objs/suite /cygdrive/d/Mozilla/tip/mozilla/configure Adding configure options from D:\Mozilla\tip\mozilla\mozconfig-suite: --enable-application=suite --enable-debug --disable-optimize --disable-tests --disable-activex --disable-activex-scripting --disable-xpconnect-idispatch --disable-accessibility loading cache ./config.cache checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking build system type... i686-pc-cygwin checking for gawk... gawk checking for nsinstall... /cygdrive/d/Mozilla/moztools/bin/nsinstall checking for gcc... cl checking whether the C compiler (cl ) works... yes checking whether the C compiler (cl ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cl accepts -g... no checking for c++... cl checking whether the C++ compiler (cl ) works... yes checking whether the C++ compiler (cl ) is a cross-compiler... no checking whether we are using GNU C++... no checking whether cl accepts -g... no checking for ranlib... ranlib checking for ml... no checking for as... /usr/bin/as checking for ar... ar checking for ld... link checking for strip... strip checking for windres... windres checking for midl... midl configure: error: The linker major version, , does not match the compiler suite version, 8. *** Fix above errors and then restart with "make -f client.mk build" make[1]: *** [configure] Error 1 make[1]: Leaving directory `/cygdrive/d/Mozilla/tip/mozilla' make: *** [/cygdrive/d/Mozilla/tip/mozilla/../objs/suite/Makefile] Error 2
Is your path correct? This is usually because the Cygwin link.exe is ahead of the Microsoft link.exe. "where link" should tell you which it's trying to use. Common solution is to rename cygwin/bin/link.exe, or put Microsoft paths in front of the Cygwin paths in your PATH environment variable. See also http://developer.mozilla.org/en/docs/Mozilla_Build_FAQ ("the linker major version").
Bingo (for that step - my build still fails a little later for some reason which I am still to look at). But changing the PATH does the trick for midl indeed. It is bit at odd with the other instruction to "Prepend Cygwin path", which I had followed: http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites#Configure_the_Environment There should probably be a big warning there.
It would also be nice if configure.in were changed to detect this situation and display a more precise error message. I've hit this multiple times.
Documentation fixed.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
The other error I am getting now is: "Cannot open include file: 'windows.h': No such file or directory" make[4]: Entering directory `/cygdrive/d/Mozilla/tip/objs/suite/nsprpub/config' sh /cygdrive/d/Mozilla/tip/mozilla/nsprpub/build/cygwin-wrapper cl -Fonow.obj -c -W3 -nologo -GF -Gy -Od -MDd -Z7 -UNDEBUG -DDEBUG_rbs -UWINNT -DMOZILLA _CLIENT=1 -DDEBUG=1 -DXP_PC=1 -DWIN32=1 -D_DEBUG=1 -DWIN95=1 -D_PR_GLOBAL_THREAD S_ONLY=1 -D_X86_=1 -DFORCE_PR_LOG /cygdrive/d/Mozilla/tip/mozilla/nsprpub/con fig/now.c now.c d:/Mozilla/tip/mozilla/nsprpub/config/now.c(46) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory make[4]: *** [now.obj] Error 2 make[4]: Leaving directory `/cygdrive/d/Mozilla/tip/objs/suite/nsprpub/config' make[3]: *** [export] Error 2 make[3]: Leaving directory `/cygdrive/d/Mozilla/tip/objs/suite/nsprpub' make[2]: *** [nspr] Error 2 make[2]: Leaving directory `/cygdrive/d/Mozilla/tip/objs/suite' make[1]: *** [default] Error 2 make[1]: Leaving directory `/cygdrive/d/Mozilla/tip/objs/suite'
Looks like you don't have the SDK (or don't have the SDK in your INCLUDE envvar).
I installed the SDK per the instructions and left it as-is after installation. Following your post, I uncommented the setting of the paths (as indicated for VC7 in the instructions --- under "Only required for MSVC7"). But I now get another kind of error: D:\Mozilla\tip\mozilla>make -f client.mk build make: pwd: Command not found make: dirname: Command not found cmp: invalid option -- t cmp: Try `cmp --help' for more information. mv: accessing `mp1964': No such file or directory client.mk:465: /.mozconfig.mk: No such file or directory client.mk:466: /build/unix/modules.mk: No such file or directory make: *** No rule to make target `/build/unix/modules.mk'. Stop. ==== What about the case of VC8 express?
This is not the right place to be discussing this ;-) The main build page doesn't cover the express (free) editions, there is a link which talks about the unique requirements for the free compiler. The free compiler doesn't come with the SDK, an assembler, MFC headers or libraries, and ATL headers or libraries. pwd/cmd errors means cygwin is not in your path correctly.
This is a real issue. Not just an empty discussion or something. The page you mentioned is this: http://developer.mozilla.org/en/docs/Building_with_VC8_Express I think I have installed everything there. Here is my batch file. With it, my cygwin is fine. (It is when I set the SDK paths that the new problem arises). ========== @echo off REM http://developer.mozilla.org/en/docs/Building_with_VC8_Express set NO_MFC=1 REM BUILD TOOLS & OPTIONS REM --------------------- set MOZ_TOOLS=D:\Mozilla\moztools REM MOZCONFIG REM @see http://webtools.mozilla.org/build/configure-build.html set MOZCONFIG=D:\Mozilla\tip\mozilla\mozconfig-suite REM CVS REM --- REM set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot set CVSROOT=:ext:rbs%%maths.uq.edu.au@cvs.mozilla.org:/cvsroot set CVS_RSH=ssh set HOME=D:\Temp REM MSVS C++ REM -------- REM call "C:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.BAT" rem --- Set VCVARS to wherever the MSVC vcvars.bat file is found set VCVARS="D:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat" rem --- Set MSSDK to wherever the MS SDK is installed rem --- Only required for MSVC7 REM set MSSDK="D:\Program Files\Microsoft Platform SDK" rem --- Set CYGWINBASE to wherever cygwin is installed set CYGWINBASE=D:\cygwin rem --- Set MSVC environment vars call %VCVARS% rem --- Prepend SDK paths rem --- Only required for MSVC7 REM set PATH=%MSSDK%\bin;%PATH% REM set INCLUDE=%MSSDK%\include;%INCLUDE% REM set LIB=%MSDDK%\lib;%LIB% rem --- Prepend Cygwin path rem --- This is necessary so that cygwin find is ahead of windows find.exe in the PATH REM XXXrbs set PATH=%CYGWINBASE%\bin;%PATH% set PATH=%PATH%;%CYGWINBASE%\bin rem --- moztools comes last set PATH=%PATH%;%MOZ_TOOLS%\bin
(In reply to comment #9) > REM set MSSDK="D:\Program Files\Microsoft Platform SDK" You should not quote the MSSDK environment variable even if it contains the space characters. Then uncomment and try again. Corrected example: set MSSDK=D:\Program Files\Microsoft Platform SDK
> REM set LIB=%MSDDK%\lib;%LIB% Typo of %MSSDK% ?
> > REM set LIB=%MSDDK%\lib;%LIB% > Typo of %MSSDK% ? Good catch. Inherited from the copy-paste (which needs to be fixed too): http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites#Configure_the_Environment > REM set MSSDK="D:\Program Files\Microsoft Platform SDK" > You should not quote the MSSDK environment variable even if it contains the > space characters. Then uncomment and try again. > Corrected example: > set MSSDK=D:\Program Files\Microsoft Platform SDK I corrected that and uncommented all those REMs (those supposedly "VC7 only"). Now, I don't get the problems reported in comment #7. The next error I get is this: /cygdrive/d/Mozilla/tip/mozilla/build/cygwin-wrapper /cygdrive/d/Mozilla/moztool s/bin/nsinstall -m 644 /cygdrive/d/Mozilla/tip/mozilla/js/src/fdlibm/fdlibm.h .. /../../dist/include/js make[5]: Leaving directory `/cygdrive/d/Mozilla/tip/objs/suite/js/src/fdlibm' make[5]: Entering directory `/cygdrive/d/Mozilla/tip/objs/suite/js/src' Creating .deps touch jsautocfg.h /cygdrive/d/Mozilla/tip/mozilla/build/cygwin-wrapper link -NOLOGO -OUT:host_jskw gen.exe -PDB:host_jskwgen.pdb host_jskwgen.obj LINK : fatal error LNK1104: cannot open file 'LIBC.lib' make[5]: *** [host_jskwgen.exe] Error 80
make clean didn't delete the file 'host_jskwgen.obj'. >rm -f .md .bak core Templates.DB jsautokw.h host_jskwgen.exe host_jskwgen.e >xe.obj jscpucfg.o jsautocfg.h jsautocfg.tmp jscpucfg js3250.dll host_jskwge >... It's trying to delete 'host_jskwgen.exe.obj' instead (maybe we should file another bug about this issue). > LINK : fatal error LNK1104: cannot open file 'LIBC.lib' > make[5]: *** [host_jskwgen.exe] Error 80 LIBC.lib (single thread library) does no longer exist on VC8. What happens if you delete old host_jskwgen.obj manually?
I restarted after simply manually deleting all the objs/suite/* to prevent similar troubles once for all. Then, the (re)compilation made some good progress, and the next error that comes up is: /cygdrive/d/Mozilla/tip/mozilla/build/cygwin-wrapper cl -Fod:/Mozilla/tip/objs/s uite/nss/freebl/WIN95_SINGLE_SHLIB/mpcpucache.obj -c -Od -Z7 -MDd -W3 -nologo -D XP_PC -DSHLIB_SUFFIX=\"dll\" -DSHLIB_PREFIX=\"\" -DSHLIB_VERSION=\"3\" -DSOFTOKE N_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -DDEBUG -D_DEBUG -UNDEBUG -DDEBU G_rbs -DWIN32 -D_WINDOWS -D_X86_ -DWIN95 -DMP_ASSEMBLY_MULTIPLY -DMP_ASSEMBLY_SQ UARE -DMP_ASSEMBLY_DIV_2DX1D -DMP_USE_UINT_DIGIT -DMP_NO_MP_WORD -DMP_API_COMPA TIBLE -Id:/Mozilla/tip/objs/suite/dist/include/nspr -Id:/Mozilla/tip/objs/suite/ dist/include -Id:/Mozilla/tip/objs/suite/dist/public/nss -Id:/Mozilla/tip/objs/ suite/dist/private/nss -Id:/Mozilla/tip/objs/suite/dist/include -Id:/Mozilla/tip /objs/suite/dist/include/dbm -Impi -Iecl d:/Mozilla/tip/mozilla/security/nss/li b/freebl/mpi/mpcpucache.c mpcpucache.c ml.exe -Fod:/Mozilla/tip/objs/suite/nss/freebl/WIN95_SINGLE_SHLIB/mpi_x86.obj -C p -Sn -Zi -coff -Id:/Mozilla/tip/objs/suite/dist/include/nspr -Id:/Mozilla/tip/o bjs/suite/dist/include -Id:/Mozilla/tip/objs/suite/dist/public/nss -Id:/Mozilla /tip/objs/suite/dist/private/nss -Id:/Mozilla/tip/objs/suite/dist/include -Id:/M ozilla/tip/objs/suite/dist/include/dbm -Impi -Iecl -c mpi/mpi_x86.asm make[7]: ml.exe: Command not found make[7]: *** [d:/Mozilla/tip/objs/suite/nss/freebl/WIN95_SINGLE_SHLIB/mpi_x86.ob j] Error 127
You currently need the assembler (ml.exe) to build NSS. See https://bugzilla.mozilla.org/show_bug.cgi?id=324448#c10 and http://developer.mozilla.org/en/docs/Building_with_VC8_Express And please, build support belongs in the mozilla.dev.builds newsgroup, not in a bug!
Finally, I got my build again! Thanks guys. The benefits of this "bug" in uncovering the slip-ups in the VC8 Express "instructions" should be obvious by now to an observer, and it is clear that they had not had a step-by-step testing as this "bug" provided. You should thank me for driving the thing (as a suffering guinea pig). I had installed the "Windows 98 DDK". But the "instructions" missed another thing. I had to add its path in my batch file: set MS98DDK=D:\98DDK set PATH=%PATH%;%MS98DDK%\bin;%MS98DDK%\bin\win98 With that, and the other earlier fixes above, my build is back again. Hope the instructions can be tuned to save others from experiencing the same troubles. In fact, simply pointing to this "bug" will be a relief to others.
Summary: Cannot build because of midl mismatch → Cannot build with the free VC8 Express Edition
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.