Closed Bug 1516090 Opened 6 years ago Closed 6 years ago

Local Windows builds busted: midl : command line error MIDL1005 : cannot find C preprocessor cl.exe (working automation) - Workaround: export PATH=$PATH:/path/to/msvc/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64

Categories

(Thunderbird :: Build Config, defect)

defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 66.0

People

(Reporter: jorgk-bmo, Unassigned)

References

Details

Attachments

(1 file)

1:31.18 64 bit Processing c:\mozilla-source\comm-central\comm\mailnews\mapi\mapihook\build\msgMapi.idl 1:31.18 midl : command line error MIDL1005 : cannot find C preprocessor cl.exe 1:31.18 mozmake[4]: *** [Makefile:26: done_gen] Error 1005 1:31.19 mozmake[3]: *** [c:/mozilla-source/comm-central/config/recurse.mk:101: comm/mailnews/mapi/mapihook/build/export] Error 2 https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b23630094b9c&tochange=42d4ad944a37 Looks like this was caused by one of these: fcf2cca505d4 Mike Hommey — Bug 1515579 - Use absolute paths for compilers, etc. r=ted 1d645417b082 Mike Hommey — Bug 1515579 - Add some mk_export_correct_style to win64-aarch64 mozconfig. r=ted 2c4de7449db2 Mike Hommey — Bug 1515852 - Move --with-system-jpeg to python configure. r=froydnj ca959629000b alwu — Bug 1505250 - change state to 'completedState' if we can't get any sample anymore. r=jya eb4b6440b878 Mike Hommey — Bug 1515595 - Move AR to python configure. r=froydnj d517c2d33a60 Mike Hommey — Bug 1515595 - Remove AR_EXTRACT. r=froydnj a415ca5d5ffd Mike Hommey — Bug 1515843 - Remove HOST_AR/HOST_RANLIB. r=ted ec095af21520 Mike Hommey — Bug 1515843 - Stop building host static libraries. r=ted 2fa138ebd75d Mike Hommey — Bug 1515843 - Use the raw OBJ_SUFFIX for host objects. r=ted f3c445024b97 Mike Hommey — Bug 1515832 - Don't build the xpcom standalone glue as a real static library. r=froydnj 00a81323e3a8 Mike Hommey — Bug 1515566 - Allow to only give a CPU type to configure's --target. r=chmanchester 5d8df624d016 Mike Hommey — Bug 1515526 - Remove need_help_dependency arguments in python configure code. r=chmanchester e8700e52f777 Mike Hommey — Bug 1515901 - Avoid loading mozconfig multiple times from MozbuildObject. r=froydnj 48b059d9a1de Mike Hommey — Bug 1514400 - Download minidump_stackwalk by default. r=ahal
Flags: needinfo?(rob)
Flags: needinfo?(mh+mozilla)
Severity: normal → blocker
BTW, before I did a clobber that started compiling the TB specific MAPI stuff, there was an error white/after linking xul.dll. 0:15.04 toolkit/library/xul.dll 0:42.14 Traceback (most recent call last): 0:42.14 File "c:\mozilla-build\python\Lib\runpy.py", line 174, in _run_module_as_main 0:42.14 "__main__", fname, loader, pkg_name) 0:42.14 File "c:\mozilla-build\python\Lib\runpy.py", line 72, in _run_code 0:42.14 exec code in run_globals 0:42.14 File "c:\mozilla-source\comm-central\python\mozbuild\mozbuild\action\check_binary.py", line 376, in <module> 0:42.14 sys.exit(main(sys.argv[1:])) 0:42.14 File "c:\mozilla-source\comm-central\python\mozbuild\mozbuild\action\check_binary.py", line 372, in main 0:42.14 return checks(TARGET, options.binary) 0:42.14 File "c:\mozilla-source\comm-central\python\mozbuild\mozbuild\action\check_binary.py", line 337, in checks 0:42.14 c(target, binary) 0:42.14 File "c:\mozilla-source\comm-central\python\mozbuild\mozbuild\action\check_binary.py", line 176, in check_nsmodules 0:42.14 for line in get_output('dumpbin.exe', '-exports', binary): 0:42.14 File "c:\mozilla-source\comm-central\python\mozbuild\mozbuild\util.py", line 935, in __call__ 0:42.14 self[args] = self.func(*args) 0:42.14 File "c:\mozilla-source\comm-central\python\mozbuild\mozbuild\action\check_binary.py", line 58, in get_output 0:42.14 return subprocess.check_output(cmd, env=env).splitlines() 0:42.14 File "c:\mozilla-build\python\Lib\subprocess.py", line 216, in check_output 0:42.14 process = Popen(stdout=PIPE, *popenargs, **kwargs) 0:42.14 File "c:\mozilla-build\python\Lib\subprocess.py", line 394, in __init__ 0:42.14 errread, errwrite) 0:42.14 File "c:\mozilla-build\python\Lib\subprocess.py", line 644, in _execute_child 0:42.14 startupinfo) 0:42.14 WindowsError: [Error 2] The system cannot find the file specified 0:42.14 mozmake[4]: *** [c:/mozilla-source/comm-central/config/rules.mk:700: xul.dll] Error 1 0:42.14 mozmake[4]: *** Deleting file 'xul.dll' 0:42.17 mozmake[3]: *** [c:/mozilla-source/comm-central/config/recurse.mk:74: toolkit/library/target] Error 2 0:42.18 mozmake[2]: *** [c:/mozilla-source/comm-central/config/recurse.mk:34: compile] Error 2 0:42.18 mozmake[1]: *** [c:/mozilla-source/comm-central/config/rules.mk:424: default] Error 2 0:42.18 mozmake: *** [client.mk:125: build] Error 2 That's why I did the clobber in the first place. So I guess other FF developers on Windows will be affected as well, CCing a few here.
Looks like linux build are busted as well, locally. No idea if it's the same cause. I think Ben also had build failures Friday so perhaps the linux failures started earlier. 28:21.08 toolkit/library/symverscript.stub 28:21.11 make[4]: *** No rule to make target '../../media/libdav1d/asm/config.o', needed by 'libxul.so'. Stop. 28:21.11 make[4]: *** Waiting for unfinished jobs.... 28:21.28 make[3]: *** [/home/magnus/Code/tb/mozilla/config/recurse.mk:74: toolkit/library/target] Error 2 28:21.28 make[3]: *** Waiting for unfinished jobs.... 29:05.68 js/src/jsapi-tests/jsapi-tests 29:06.74 make[2]: *** [/home/magnus/Code/tb/mozilla/config/recurse.mk:34: compile] Error 2 29:06.74 make[1]: *** [/home/magnus/Code/tb/mozilla/config/rules.mk:424: default] Error 2 29:06.74 make: *** [client.mk:125: build] Error 2
Building on https://hg.mozilla.org/mozilla-central/rev/b723ef9caca9 (before the build config changesets) works.
Can you try the following change? --- a/toolkit/moz.configure +++ b/toolkit/moz.configure @@ -1095,17 +1095,17 @@ midl = check_prog('MIDL', midl_names, when=check_for_midl, allow_missing=True, @depends(c_compiler, target, when=depends(midl, target)(lambda m, t: m and t.kernel == 'WINNT')) def midl_flags(c_compiler, target): if c_compiler and c_compiler.type in ('msvc', 'clang-cl'): env = { 'x86': 'win32', 'x86_64': 'x64', 'aarch64': 'arm64', }[target.cpu] - return ['-env', env] + return ['-env', env, '-cpp_cmd', c_compiler.compiler] # mingw return { 'x86': ['--win32', '-m32'], 'x86_64': ['--win64', '-m64'], }[target.cpu] > 28:21.11 make[4]: *** No rule to make target '../../media/libdav1d/asm/config.o', needed by 'libxul.so'. Stop. See https://groups.google.com/d/msg/mozilla.dev.platform/o-8levmLU80/_-igGI7_AQAJ
Flags: needinfo?(mh+mozilla)
(In reply to Mike Hommey [:glandium] from comment #4) > Can you try the following change? > - return ['-env', env] > + return ['-env', env, '-cpp_cmd', c_compiler.compiler] Still fails with the same errors of comment 1. Backout of https://hg.mozilla.org/mozilla-central/rev/fcf2cca505d4 let me build successfully.
(In reply to Mike Hommey [:glandium] from comment #4) Right, mach bootstrap fixed the build for linux.
|mach bootstrap| doesn't fix the issue on Windows. I seems to install clang, cbindgen, node and clang-tidy, I'm not sure whether "nasm" is part of that mix. - return ['-env', env] + return ['-env', env, '-cpp_cmd', c_compiler.compiler] changes the error to: 0:55.83 clang-cl.exe: warning: c:\mozilla-source\comm-central\comm\mailnews\mapi\mapihook\build\msgMapi.idl: 'linker' input unused [-Wunused-command-line-argument] 0:55.83 clang-cl.exe: warning: argument unused during compilation: '-I c:/mozilla-source/comm-central/comm/mailnews/mapi/mapihook/build' [-Wunused-command-line-argument] 0:55.83 clang-cl.exe: warning: argument unused during compilation: '-D __midl=801' [-Wunused-command-line-argument] 0:55.83 64 bit Processing c:\mozilla-source\comm-central\accessible\interfaces\msaa\ISimpleDOM.idl 0:55.83 Microsoft (R) 32b/64b MIDL Compiler Version 8.01.0622 0:55.83 Copyright (c) Microsoft Corporation. All rights reserved. 0:55.83 c:\mozilla-source\comm-central\comm\mailnews\mapi\mapihook\build\msgMapi.idl(1) : error MIDL2183 : unexpected end of file found 0:55.83 Microsoft (R) 32b/64b MIDL Compiler Version 8.01.0622 0:55.83 Copyright (c) Microsoft Corporation. All rights reserved. 0:55.83 devtools/client/debugger/new/src/node.stub.stub 0:55.83 mozmake[4]: *** [Makefile:26: done_gen] Error 2026 Similar errors for M-C code follow: 0:55.91 64 bit Processing c:\mozilla-source\comm-central\accessible\interfaces\ia2\IA2Typelib.idl 0:55.91 mozmake[3]: *** [c:/mozilla-source/comm-central/config/recurse.mk:101: accessible/ipc/win/typelib/export] Error 2 0:55.93 mozmake[3]: *** [c:/mozilla-source/comm-central/config/recurse.mk:101: accessible/ipc/win/handler/export] Error 2 0:55.93 clang-cl.exe: warning: c:\mozilla-source\comm-central\other-licenses\ia2\Accessible2.idl: 'linker' input unused [-Wunused-command-line-argument] 0:55.93 clang-cl.exe: warning: argument unused during compilation: '-I c:/mozilla-source/comm-central/other-licenses/ia2' [-Wunused-command-line-argument] 0:55.93 clang-cl.exe: warning: argument unused during compilation: '-D __midl=801' [-Wunused-command-line-argument] 0:55.93 c:\mozilla-source\comm-central\other-licenses\ia2\Accessible2.idl(1) : error MIDL2183 : unexpected end of file found 0:55.96 clang-cl.exe: warning: c:\mozilla-source\comm-central\accessible\interfaces\ia2\IA2Typelib.idl: 'linker' input unused [-Wunused-command-line-argument] 0:55.96 clang-cl.exe: warning: argument unused during compilation: '-I c:/mozilla-source/comm-central/other-licenses/ia2' [-Wunused-command-line-argument] 0:55.96 clang-cl.exe: warning: argument unused during compilation: '-D _MIDL_DECLARE_WIREM_HANDLE' [-Wunused-command-line-argument] 0:55.96 clang-cl.exe: warning: argument unused during compilation: '-D __midl=801' [-Wunused-command-line-argument] 0:55.96 c:\mozilla-source\comm-central\accessible\interfaces\ia2\IA2Typelib.idl(1) : error MIDL2183 : unexpected end of file found More ideas?
Flags: needinfo?(mh+mozilla)
(In reply to Jorg K (GMT+1) (urgent reviews and bustage fix only, Dec 22nd to Jan 1st) from comment #7) > |mach bootstrap| doesn't fix the issue on Windows. I seems to install clang, > cbindgen, node and clang-tidy, I'm not sure whether "nasm" is part of that > mix. Apparently not: 0:03.66 checking yasm version... 1.3.0 0:03.67 checking for nasm... not found
No problems here with MAPI headers. Also made clobbers. (In reply to Jorg K (GMT+1) (urgent reviews and bustage fix only, Dec 22nd to Jan 1st) from comment #8) > (In reply to Jorg K (GMT+1) (urgent reviews and bustage fix only, Dec 22nd > to Jan 1st) from comment #7) > > |mach bootstrap| doesn't fix the issue on Windows. I seems to install clang, > > cbindgen, node and clang-tidy, I'm not sure whether "nasm" is part of that > > mix. > Apparently not: > 0:03.66 checking yasm version... 1.3.0 > 0:03.67 checking for nasm... not found I have read, nasm is only on Linux used.
To work around midl : command line error MIDL1005 : cannot find C preprocessor cl.exe I copied cl.exe from C:\vs2017\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64\cl.exe to C:\mozilla-build\msys\local\bin since this is part of the PATH. Now the errors has changed to: 0:05.77 64 bit Processing c:\mozilla-source\comm-central\other-licenses\ia2\Accessible2.idl 0:05.77 midl : command line error MIDL1003 : error returned by the C preprocessor (4) So cl.exe is found now, but it apparently can't preprocess something.
Hmm, copying cl.exe wasn't a good idea, the setup then assumes that the whole Windows SDK lives at this location. Nasm will also come to Windows, see bug 1511224. So with |ac_add_options --disable-av1| in .mozconfig and Mike's suggestion reversed, I'm back to: midl : command line error MIDL1005 : cannot find C preprocessor cl.exe for the processing of various IDL files like msgMapi.idl, IGeckoCustom.idl, ISimpleDOM.idl and many more.
export PATH=$PATH:/c/vs2017/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64 seems to fix the problem. Note that I have installed MSVS in C:\vs2017.
Summary: Local Windows builds busted: midl : command line error MIDL1005 : cannot find C preprocessor cl.exe (working automation) → Local Windows builds busted: midl : command line error MIDL1005 : cannot find C preprocessor cl.exe (working automation) - Worksround: export PATH=$PATH:/path/to/msvc/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64
Summary: Local Windows builds busted: midl : command line error MIDL1005 : cannot find C preprocessor cl.exe (working automation) - Worksround: export PATH=$PATH:/path/to/msvc/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64 → Local Windows builds busted: midl : command line error MIDL1005 : cannot find C preprocessor cl.exe (working automation) - Workaround: export PATH=$PATH:/path/to/msvc/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64
This is when you use VC as compiler and not clang?
No, with clang-cl. The MSVC compiler is still used for some jobs, like the midl processing :-(
export PATH=$PATH:/c/vs2017/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64 depends on where your MSVC is installed, whether you have an x64 OS and compiling 64bit. There are four copies of cl.exe for the various combinations, but I'm doing 64bit on 64bit. I guess for 32bit compile on a x64 OS it would be /Hostx64/x86.
Flags: needinfo?(rob)
This doesn't work for me. With a default installation I've set the path: export PATH=$PATH:/c/Program\ Files\ \(x86\)/Microsoft\ Visual\ Studio/2017/Community/VC/Tools/MSVC/14.15.26726/bin/Hostx64/x64
I knew why I didn't want spaces in the path ;-) Try: export PATH=$PATH:"/c/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.15.26726/bin/Hostx64/x64"
This doesn't work here.
Well, you can create a hard link in Windows: mklink /h c:\vs2017\VC "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC" in a privileged DOS shell, or: mklink /h c:\vs2017\ "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\" Then in the Mozilla shell: export PATH=$PATH:/c/vs2017/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64
The patch in comment 4 is necessary when building with MSVC on x86-64 for x86-64, and make things work then. Interestingly, using clang-cl as preprocessor with the same command doesn't seem to work...
Flags: needinfo?(mh+mozilla)
What's happening is that clang-cl doesn't want to do the preprocessing when the filename ends with .idl. It thinks it has to do something else, despite the -E option being on the command line.
This is a followup to bug 1515579. Interestingly, midl just tries "cl" in the PATH, and we've been lucky that the one it finds corresponds to the target compiler and/or that it doesn't matter what architecture the compiler targets for idl preprocessing..
Blocks: 1515528
Do I need bug 1515528 applied for this patch? With only the patch here it still fails.
Also with bug 1515528 applied it still fails.
(In reply to Richard Marti (:Paenglab) from comment #25) > Also with bug 1515528 applied it still fails. Bug 1515528 is not needed. Can you provide the command line that fails, along with the error message?
This is what I get: 23:54.85 toolkit/library/xul.dll 24:13.18 Traceback (most recent call last): 24:13.18 File "c:\mozilla-build\python\Lib\runpy.py", line 174, in _run_module_as_main 24:13.18 "__main__", fname, loader, pkg_name) 24:13.18 File "c:\mozilla-build\python\Lib\runpy.py", line 72, in _run_code 24:13.18 exec code in run_globals 24:13.18 File "z:\Mozilla\comm-central\python\mozbuild\mozbuild\action\check_binary.py", line 376, in <module> 24:13.18 sys.exit(main(sys.argv[1:])) 24:13.18 File "z:\Mozilla\comm-central\python\mozbuild\mozbuild\action\check_binary.py", line 372, in main 24:13.18 return checks(TARGET, options.binary) 24:13.18 File "z:\Mozilla\comm-central\python\mozbuild\mozbuild\action\check_binary.py", line 337, in checks 24:13.18 c(target, binary) 24:13.18 File "z:\Mozilla\comm-central\python\mozbuild\mozbuild\action\check_binary.py", line 176, in check_nsmodules 24:13.18 for line in get_output('dumpbin.exe', '-exports', binary): 24:13.18 File "z:\Mozilla\comm-central\python\mozbuild\mozbuild\util.py", line 935, in __call__ 24:13.18 self[args] = self.func(*args) 24:13.18 File "z:\Mozilla\comm-central\python\mozbuild\mozbuild\action\check_binary.py", line 58, in get_output 24:13.18 return subprocess.check_output(cmd, env=env).splitlines() 24:13.18 File "c:\mozilla-build\python\Lib\subprocess.py", line 216, in check_output 24:13.18 process = Popen(stdout=PIPE, *popenargs, **kwargs) 24:13.18 File "c:\mozilla-build\python\Lib\subprocess.py", line 394, in __init__ 24:13.18 errread, errwrite) 24:13.18 File "c:\mozilla-build\python\Lib\subprocess.py", line 644, in _execute_child 24:13.18 startupinfo) 24:13.18 WindowsError: [Error 2] Das System kann die angegebene Datei nicht finden 24:13.18 mozmake.EXE[4]: *** [z:/Mozilla/comm-central/config/rules.mk:700: xul.dll] Error 1 24:13.18 mozmake.EXE[4]: *** Deleting file 'xul.dll' 24:13.18 mozmake.EXE[3]: *** [z:/Mozilla/comm-central/config/recurse.mk:74: toolkit/library/target] Error 2 24:13.18 mozmake.EXE[3]: *** Waiting for unfinished jobs.... 24:13.20 mozmake.EXE[2]: *** [z:/Mozilla/comm-central/config/recurse.mk:34: compile] Error 2 24:13.20 mozmake.EXE[1]: *** [z:/Mozilla/comm-central/config/rules.mk:424: default] Error 2 24:13.21 mozmake.EXE: *** [client.mk:125: build] Error 2
That's a very different error. Can you file a separate bug for that one?
Setting the path like in comment 17 works for me. The patch does not. (In reply to Mike Hommey [:glandium] from comment #26) > Bug 1515528 is not needed. Can you provide the command line that fails, > along with the error message? | 5:17.64 comm/mailnews/base/search/src | 5:24.84 Compiling winapi v0.3.6 (https://github.com/froydnj/winapi-rs?branch=aarch64#4e52ee21) | 5:30.53 Compiling unicode-xid v0.1.0 | 5:31.33 Compiling winapi v0.3.6 (https://github.com/froydnj/winapi-rs?branch=aarch64#4e52ee21) 'aarch64'? I use: ac_add_options --target=x86_64-pc-mingw32 ac_add_options --host=x86_64-pc-mingw32 | 5:32.28 error: linker `link.exe` not found | 5:32.28 | | 5:32.28 = note: Das System kann die angegebene Datei nicht finden. (os error 2) | 5:32.28 note: the msvc targets depend on the msvc linker but `link.exe` was not found | 5:32.28 note: please ensure that VS 2013, VS 2015 or VS 2017 was installed with the Visual C++ option | 5:32.28 error: aborting due to previous error | 5:32.64 error: Could not compile `winapi`. | 5:32.64 To learn more, run the command again with --verbose. | 5:32.69 mozmake.EXE[4]: *** [s:/Projects/mozi/mozilla/config/rules.mk:1102: force-cargo-host-program-build] Error 101 | 5:32.69 mozmake.EXE[3]: *** [s:/Projects/mozi/mozilla/config/recurse.mk:74: js/src/frontend/binsource/host] Error 2 | 5:32.69 mozmake.EXE[3]: *** Waiting for unfinished jobs.... | 5:34.59 Compiling serde v1.0.80 | 5:38.08 error: linker `link.exe` not found | 5:38.08 | | 5:38.08 = note: Das System kann die angegebene Datei nicht finden. (os error 2)
(In reply to Mike Hommey [:glandium] from comment #28) > That's a very different error. Can you file a separate bug for that one? Filed bug 1516228
(In reply to Alfred Peters from comment #29) > | 5:32.28 error: linker `link.exe` not found That's yet another error. Please file another separate bug for this one
Blocks: 1516253
Building with this patch does get past the initial issue but fails later on with this: 165:25.66 return subprocess.check_output(cmd, env=env).splitlines() 165:25.66 File "c:\mozilla-build\python\Lib\subprocess.py", line 212, in check _output 165:25.66 process = Popen(stdout=PIPE, *popenargs, **kwargs) 165:25.66 File "c:\mozilla-build\python\Lib\subprocess.py", line 390, in __ini t__ 165:25.66 errread, errwrite) 165:25.66 File "c:\mozilla-build\python\Lib\subprocess.py", line 640, in _exec ute_child 165:25.66 startupinfo) 165:25.66 WindowsError: [Error 2] The system cannot find the file specified 165:25.66 mozmake.EXE[4]: *** [c:/Users/wag/mozilla/mozilla2/config/rules.mk:700 : xul.dll] Error 1 165:25.66 mozmake.EXE[4]: *** Deleting file 'xul.dll' 165:25.66 mozmake.EXE[3]: *** [c:/Users/wag/mozilla/mozilla2/config/recurse.mk:7 4: toolkit/library/target] Error 2 165:25.66 mozmake.EXE[2]: *** [c:/Users/wag/mozilla/mozilla2/config/recurse.mk:3 4: compile] Error 2 165:25.72 mozmake.EXE[1]: *** [c:/Users/wag/mozilla/mozilla2/config/rules.mk:424 : default] Error 2 Using the workaround form comment #15 results in a successful build.
OK last post was missing part of the log was trying to post this: 165:25.50 Traceback (most recent call last): 165:25.64 File "c:\mozilla-build\python\Lib\runpy.py", line 174, in _run_modul e_as_main 165:25.64 "__main__", fname, loader, pkg_name) 165:25.64 File "c:\mozilla-build\python\Lib\runpy.py", line 72, in _run_code 165:25.64 exec code in run_globals 165:25.64 File "c:\Users\wag\mozilla\mozilla2\python\mozbuild\mozbuild\action\ check_binary.py", line 376, in <module> 165:25.64 sys.exit(main(sys.argv[1:])) 165:25.64 File "c:\Users\wag\mozilla\mozilla2\python\mozbuild\mozbuild\action\ check_binary.py", line 372, in main 165:25.66 return checks(TARGET, options.binary) 165:25.66 File "c:\Users\wag\mozilla\mozilla2\python\mozbuild\mozbuild\action\ check_binary.py", line 337, in checks 165:25.66 c(target, binary) 165:25.66 File "c:\Users\wag\mozilla\mozilla2\python\mozbuild\mozbuild\action\ check_binary.py", line 176, in check_nsmodules 165:25.66 for line in get_output('dumpbin.exe', '-exports', binary): 165:25.66 File "c:\Users\wag\mozilla\mozilla2\python\mozbuild\mozbuild\util.py ", line 935, in __call__ 165:25.66 self[args] = self.func(*args) 165:25.66 File "c:\Users\wag\mozilla\mozilla2\python\mozbuild\mozbuild\action\check_binary.py", line 58, in get_output 165:25.66 return subprocess.check_output(cmd, env=env).splitlines() 165:25.66 File "c:\mozilla-build\python\Lib\subprocess.py", line 212, in check _output 165:25.66 process = Popen(stdout=PIPE, *popenargs, **kwargs) 165:25.66 File "c:\mozilla-build\python\Lib\subprocess.py", line 390, in __ini t__ 165:25.66 errread, errwrite) 165:25.66 File "c:\mozilla-build\python\Lib\subprocess.py", line 640, in _exec ute_child 165:25.66 startupinfo) 165:25.66 WindowsError: [Error 2] The system cannot find the file specified 165:25.66 mozmake.EXE[4]: *** [c:/Users/wag/mozilla/mozilla2/config/rules.mk:700 : xul.dll] Error 1 165:25.66 mozmake.EXE[4]: *** Deleting file 'xul.dll' 165:25.66 mozmake.EXE[3]: *** [c:/Users/wag/mozilla/mozilla2/config/recurse.mk:7 4: toolkit/library/target] Error 2 165:25.66 mozmake.EXE[2]: *** [c:/Users/wag/mozilla/mozilla2/config/recurse.mk:3 4: compile] Error 2 165:25.72 mozmake.EXE[1]: *** [c:/Users/wag/mozilla/mozilla2/config/rules.mk:424 : default] Error 2
Blocks: 1515579
No longer blocks: 1515528, 1516253
For a 64-bt build the best workaround is this: MSVC_VER=`ls "/c/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/" | head -1` export PATH="$PATH:/C/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/$MSVC_VER/bin/Hostx64/x64"
Bug 1515579 was backed out, so no workaround needed anymore.
And that was not even the best workaround. this would have been better: MSVC_VER=`ls -t "/c/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/" | head -1` export PATH="$PATH:/C/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/$MSVC_VER/bin/Hostx64/x64"
Pushed by mh@glandium.org: https://hg.mozilla.org/integration/autoland/rev/332aad533b7a Explicitly pass the compiler/preprocessor path to midl. r=froydnj
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 66.0
Depends on: 1523144
Blocks: 1537641
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: