Closed Bug 1516090 Opened Last year Closed Last year

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, blocker)

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..
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
https://hg.mozilla.org/mozilla-central/rev/332aad533b7a
Status: NEW → RESOLVED
Closed: Last year
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.