yasm.exe looks for msvcr100.dll, which is part of the Visual Studio 2010 C++ redistributable package. Yasm errors out during configuration (at least when configuring SpiderMonkey for standalone JS shell builds) when trying to check its version. This requirement does not appear to be mentioned on the page with build prerequisites (https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Windows_Prerequisites). Ideally we'd ship a yasm.exe that requires only the MSVC 2015 or 2017 redistributable as part of Mozillabuild 3.
Component: Build Config → MozillaBuild
Product: Core → mozilla.org
Version: unspecified → other
I hit this when installing a new build environment on a windows 2016 EC2 instance.
And watchman wants msvcr120.dll, from Visual Studio 2013 C++ redistributable package
I'm going to try just building it locally with a static link to the CRT to work around this issue. (In reply to Mike Hommey [:glandium] from comment #2) > And watchman wants msvcr120.dll, from Visual Studio 2013 C++ redistributable > package I'm disabling fsmonitor by default, so that should be a non-issue again for now. Can you please file this in a new bug for proper tracking?
I just ran into this (yasm requiring msvcr100.dll) while doing a fresh install on Windows 10.
I also just hit this. I suspect this will be more common as people do fresh configurations that never had VS2010 installed. Any chance we could get this prioritized? (Also who is the triage owner for this component?)
(For anyone else with this issue, installing https://download.microsoft.com/download/3/2/2/3224B87F-CFA0-4E70-BDA3-3DE650EFEBA5/vcredist_x64.exe worked for me.)
In theory the build system owns MozillaBuild. In reality, RyanVM still does things. RyanVM: do you have any interest in fixing yasm.exe? How could someone else help?
Flags: needinfo?(gps) → needinfo?(ryanvm)
I took a look at compiling yasm with VS2017 but couldn't get a successful build. I don't have the cycles to dig into it at this point, so I guess we can either just side-load the DLL alongside yasm and be done with it or someone else can try to get a working build going that we can ship instead.
Shipping the DLLs alongside yasm.exe seems like a totally sensible workaround. (Really they just need to wind up in $PATH somewhere.)
Let's just bundle the DLL and get on with life.
Assignee: nobody → ryanvm
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/mozilla-build/rev/0500d992f0cf Bundle msvcr100.dll with yasm to avoid missing runtime errors.
Status: NEW → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.