Closed Bug 1293675 Opened 3 years ago Closed 3 years ago

recipe for target 'crashreporter.exe' failed - c:/PROGRA~2/Windows no such file or directory

Categories

(Toolkit Graveyard :: Build Config, defect)

defect
Not set

Tracking

(firefox52 fixed)

RESOLVED FIXED
mozilla52
Tracking Status
firefox52 --- fixed

People

(Reporter: chutten, Unassigned)

References

Details

Attachments

(4 files)

The following build failure on ./mach build on my Windows 10 (Anniversary Update) laptop:

 0:52.29 Embedding manifest from c:/msys64/home/Chris/gecko/toolkit/crashreporter/client/crashreporter.exe.manifest
 0:52.32 C:/Users/Chris/AppData/Local/Temp/make13768-1.sh: line 11: c:/PROGRA~2/Windows: No such file or directory
 0:52.34 c:/msys64/home/Chris/gecko/config/rules.mk:656: recipe for target 'crashreporter.exe' failed
 0:52.35 mozmake.EXE[5]: *** [crashreporter.exe] Error 127
 0:52.37 mozmake.EXE[5]: *** Deleting file 'crashreporter.exe'
 0:52.37 c:/msys64/home/Chris/gecko/config/recurse.mk:71: recipe for target 'toolkit/crashreporter/client/target' failed
 0:52.37 mozmake.EXE[4]: *** [toolkit/crashreporter/client/target] Error 2
 0:52.38 mozmake.EXE[4]: *** Waiting for unfinished jobs....

Near as I can tell from looking for "Embedding manifest from", it's using a tool called "mt.exe" from the Windows SDK to do something with manifests.

$ which mt
/c/Program Files (x86)/Windows Kits/8.1/bin/x64/mt.exe

Looks like something 8.3'd the second segment of the path, but didn't do it for the third?

I tried putting a copy of mt.exe in /local/bin so it could be found in a non-space-having part of the path, but no joy. I think something's reading WINDOWSSDKDIR or UNIVERSALCRTSDKDIR or SDKDIR or NETFXSDKDIR or something, and munging it up pretty badly.
Please attach the output of mach configure.
Flags: needinfo?(chutten)
Flags: needinfo?(chutten)
WTF does GetShortPathNameW not do its job? What version of Windows is this?
Windows 10 Anniversary Update (Windows build number... Lessee Version 1607 (OS Build 14393.10)
I'm unable to reproduce on Windows 10 Anniversary Update Build 14393. I'm getting 8.3 paths for all path components, not just the leading one.
Do you have an antivirus installed or something else that would alter GetShortPathNameW's behavior?
Flags: needinfo?(chutten)
Windows Defender and Kaspersky Endpoint Security 10.
Flags: needinfo?(chutten)
Hm. Apparently Kaspersky Endpoint Security 10, though appearing to be installed, isn't running a service.
Well, indeed it is GetShortPathName that's to blame, as the attached program generates (for me) 

long name = C:\Program Files (x86)\Windows Kits\8.1\ shortname = C:\PROGRA~2\Windows Kits\8.1\

(( So too it does if I ask it to use just GetShortPathName ))

Well, I have a pending Windows Update. Let's see if that shakes things back into order.
On the Windows 10 Anniversary update, the test program generates:

long name = C:\Program Files (x86)\Windows Kits\8.1\ shortname = C:\PROGRA~2\WI3CF2~1\8.1\
Ah-ha!

c:\Program Files (x86)>fsutil 8dot3name query
The registry state is: 1 (Disable 8dot3 name creation on all volumes).

At some point (probably during the update) 8dot3 name creation was disabled on my volumes. Let's see if I can fix that...
fsutil behavior set disable8dot3 2

fsutil file setshortname "Windows Kits" WI3CF2~1

echo "Fingers Crossed" && ./mach build
`mach doctor` prompts the user to disable 8.3 filename creation... for performance reasons.

We may want to remove that.
Filed bug 1294475 to track the `mach doctor` bits.

./mach build failed possibly because I forgot to refresh the configuration. So now it's

echo "Fingers Crossed" && ./mach configure && ./mach build
That did it. Actually able to build and run now.

Sorry for the noise.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Actually, I think we should error out directly in configure if GetShortPathName gives out paths with spaces, at least until the build system is able to deal with them.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Duplicate of this bug: 1304183
Duplicate of this bug: 1313769
Comment on attachment 8806165 [details]
Bug 1293675 - Error out when GetShortPathName returns a long path name.

https://reviewboard.mozilla.org/r/89664/#review89082
Attachment #8806165 - Flags: review?(gps) → review+
Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/6c105cd2bf71
Error out when GetShortPathName returns a long path name. r=gps
Comment on attachment 8806165 [details]
Bug 1293675 - Error out when GetShortPathName returns a long path name.

With adjusted unit tests so that they don't fail because of the new check.
Attachment #8806165 - Flags: review+ → review?(gps)
Comment on attachment 8806165 [details]
Bug 1293675 - Error out when GetShortPathName returns a long path name.

https://reviewboard.mozilla.org/r/89664/#review89314
Attachment #8806165 - Flags: review?(gps) → review+
Pushed by gszorc@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7eed7e4fda99
Error out when GetShortPathName returns a long path name. r=gps
https://hg.mozilla.org/mozilla-central/rev/7eed7e4fda99
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
See Also: → 1323381
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.