Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WpfGfx doesn't compile #2561

Closed
wjk opened this issue Feb 12, 2020 · 7 comments
Closed

WpfGfx doesn't compile #2561

wjk opened this issue Feb 12, 2020 · 7 comments

Comments

@wjk
Copy link
Contributor

@wjk wjk commented Feb 12, 2020

  • .NET Core Version: 3.1.200-preview-014883
  • Windows version: 18362.592
  • Does the bug reproduce also in WPF for .NET Framework 4.8?: N/A, build issue

Problem description:

When I try to compile WpfGfx, I get a number of C++ static_cast errors in vector3_xm.hpp, quaternion_xm.hpp, and matrix_xm.hpp. This breaks the build.

Actual behavior:

Large number of repeated errors (see attached binlog).

Expected behavior:

It should build.

Minimal repro:

I am on commit eb6fca3. A zipped binlog is here: Build.binlog.zip

@weltkante

This comment has been minimized.

Copy link

@weltkante weltkante commented Feb 12, 2020

Works fine for me with VS 2019/16.5 preview 2 installed, running restore.cmd and then build.cmd from a powershell in the git repository on master branch. Just in case looking at the difference to my setup helps you unblocking yourself.

@vatsan-madhavan

This comment has been minimized.

Copy link
Member

@vatsan-madhavan vatsan-madhavan commented Feb 12, 2020

What @weltkante said. Any VS build > 16.4 should work. I started codifying the exact requirements at #2307, but it's still a WIP ;-).

If a commit successfully builds on Microsoft's build servers (for the purposes of validating a PR, for e.g.), it should pretty much build for anyone.

The PR builds have nothing special going on - they are just running latest preview versions of Visual studio on a Win10[-ish] build machine, create a fresh clone and run something like build -pack -platform [x86|x64] -configuration [Debug|Release]. They do supply a few additional parameters to keep track of version numbers etc., which are not quite salient for the success of a the build itself.

When trying to build a commit like eb6fca3, its reasonable to presume that should build (because otherwise it would not have been merged automatically).

I haven't seem problems like the one you've reported in that part of the codebase. That code - though heavy in use of templates etc. - used to build just fine using VS 2017 class compilers as-is (and continues to build ok for several developers and on many build-machines on VS2019 compilers over the past years). This reads like a dev-machine configuration problem to me. Unfortunately, I can't say what's going on from our logs... 😞

  • Please try to update your VS to latest preview
  • Build from a new clone
    • Try putting the clone in a short path so you don't encounter accidental MAX_PATH problems during header inclusions (C:\src\repos\wpf always works for me).
  • Don't build from within a VS Developer command prompt. Build from a vanilla prompt.
    • I prefer elevated command prompt for my builds. I suspect low-priv prompt ought to work fine.
    • Powershell vs. cmd.exe is a matter of preference.
@weltkante

This comment has been minimized.

Copy link

@weltkante weltkante commented Feb 12, 2020

your binlog contains lines like these which stand out to me:

Project file contains ToolsVersion="15.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="Current".

Don't know if thats a red herring or if you are missing an optional component in your VS install.

Unrelated to your particular problem but maybe useful for future readers who want to diagnose build problems: if the restore.cmd / build.cmd fail or get interrupted you may need to clean partially downloaded/unpacked folders:

  • clear the .tools\native\bin subfolder of the git repo (alternatively try a fresh clone)
  • C:\Users\<user>\.netcoreeng\native\temp contains download caches (remove individual files if the zip file is partially downloaded or otherwise broken)
  • C:\Users\<user>\.netcoreeng\native\bin contains unpacked downloads (remove if you suspect unpacking was interrupted/failed)

I suspect low-priv prompt ought to work fine.

I'm building unelevated sucessfully.

@wjk

This comment has been minimized.

Copy link
Contributor Author

@wjk wjk commented Feb 13, 2020

No dice. Nothing suggested here works. I also tried the vsconfig files from #2307; didn't help.

@vatsan-madhavan

This comment has been minimized.

Copy link
Member

@vatsan-madhavan vatsan-madhavan commented Feb 13, 2020

I don't have a lot of experience troubleshooting C++ failures remotely, but I'll try :-)

https://support.microsoft.com/en-za/help/974229/troubleshooting-for-the-microsoft-visual-c-compiler-or-the-visual-c-li describes how to create a reproducible preprocessor output that can be used to reproduce the compilation errors.

You can extract the failing cl.exe command from the msbuild binary log, and re-run it in a Visual Studio Developer Command Prompt while supplying additional switches as outlined in the article.

This could help us compare results in a more fine-grained manner and then back-track to the source of divergence.

/cc @tgani-msft for additional suggestions.

@wjk

This comment has been minimized.

Copy link
Contributor Author

@wjk wjk commented Feb 13, 2020

Found it! I had modified the C++ projects to build with the 18362 Windows SDK, as that's what I build all my other projects with. However, WPF actually does require the 17134 SDK, and will not compile with any newer version. When I installed that specific SDK version and rebuilt, WpfGfx compiled just fine. Thanks for all your help!

@wjk wjk closed this Feb 13, 2020
@vatsan-madhavan

This comment has been minimized.

Copy link
Member

@vatsan-madhavan vatsan-madhavan commented Feb 13, 2020

Hmm. I would have thought #2307 would have stipulated 17134 SDK to the VS installer, and using that vsconfig file would have configured Visual Studio to install the right SDK for you...

Anyway, glad to hear that this is resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.