building examples-native fails on Windows

[cormac-obrien]

Running make examples-native from the project root:

PS C:\[...]\wgpu> make examples-native
cargo build --manifest-path wgpu-native/Cargo.toml --features "local,gfx-backend-dx12"
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
cd examples/hello_triangle_c && mkdir build && cd build && cmake .. && make
-- Building for: Visual Studio 15 2017

[...]

-- Generating done
-- Build files have been written to: C:/[...]/wgpu/examples/hello_triangle_c/build
make[1]: Entering directory 'C:/[...]/wgpu/examples/hello_triangle_c/build'
make[1]: *** No targets specified and no makefile found.  Stop.
make[1]: Leaving directory 'C:/[...]/wgpu/examples/hello_triangle_c/build'
make: *** [makefile:74: examples-native] Error 2

It looks like the Makefile expects CMake to have generated another Makefile:

examples-native: lib-native $(FFI_DIR)/wgpu.h examples/hello_triangle_c/main.c
    cd examples/hello_triangle_c && $(CREATE_BUILD_DIR) && cd build && cmake .. && make

But on Windows (or at least my system) CMake generates Visual Studio project files instead.

    Directory: C:\[...]\wgpu\examples\hello_triangle_c\build

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        5/23/2019  10:57 PM                CMakeFiles
-a----        5/23/2019  10:57 PM          49613 ALL_BUILD.vcxproj
-a----        5/23/2019  10:57 PM            306 ALL_BUILD.vcxproj.filters
-a----        5/23/2019  10:57 PM          14042 CMakeCache.txt
-a----        5/23/2019  10:57 PM           1493 cmake_install.cmake
-a----        5/23/2019  10:57 PM           3211 hello_triangle.sln
-a----        5/23/2019  10:57 PM          59806 hello_triangle.vcxproj
-a----        5/23/2019  10:57 PM            613 hello_triangle.vcxproj.filters
-a----        5/23/2019  10:57 PM          48809 ZERO_CHECK.vcxproj
-a----        5/23/2019  10:57 PM            549 ZERO_CHECK.vcxproj.filters

I'm not terribly familiar with CMake so I'm not sure how to make it generate Makefiles instead.

[waywardmonkeys]

You'd want to have the cmake .. be cmake .. -G"Unix Makefiles" ... but not sure that that would entirely help here with the toolchains involved. But you can try!

[waywardmonkeys]

You might also try changing: cmake .. && make to cmake .. && cmake --build .

That'll let cmake choose how to run the build instead of always calling make.

[cormac-obrien]

Changing the final make to cmake --build . does fix this particular problem!

MSVC is failing with LINK : fatal error LNK1104: cannot open file 'glfw3.lib'. I'm not sure whether this is also a broken CMake configuration or just my GLFW installation being busted, but the fact that find_package(glfw3) succeeds while the compiler fails to find the library suggests an issue with the build config. Does find_package automatically update the compiler library path?

[Timo-DK]

Hello and thanks for creating this issue!

I am also already doing research for this problem for about two weeks now. I think that I can shine some light on the problems you're encountering because I encountered them too.

First of about the following part:

make[1]: Entering directory 'C:/[...]/wgpu/examples/hello_triangle_c/build'
make[1]: *** No targets specified and no makefile found. Stop.
make[1]: Leaving directory 'C:/[...]/wgpu/examples/hello_triangle_c/build'
make: *** [makefile:74: examples-native] Error 2

This is because "normally" the cmake .. creates an executable file while using some compilers. Especially on Linux is this the case and I think this script was initially created from a Linux perspective. This directory then also has a Makefile with some logic in it to successfully run the application, but for the Visual Studio compiler, it builds an .sln and three projects.

For us Windows users, when we have Visual Studio installed, we get complete compilers that are automatically chosen by CMake. It is possible to use MinGW64 for instance by using the -G "MinGW Makefiles". See here for more information: https://cmake.org/cmake/help/v3.9/manual/cmake-generators.7.html

Secondly about the following part:

LINK : fatal error LNK1104: cannot open file 'glfw3.lib'

I have encountered this problem too and I am always manually specifying the header file and library file to solve this temporarily in Visual Studio.

I am not sure if this automatically links the header file and library file on Linux, but on Windows it doesn't. I am not really familiar with CMake too, but I've read that it was built for Linux and it is using Linux predefined paths to look up libraries like GLFW for instance, so that could be an issue.

Did you already have had a working example ran successfully in Windows?

[cormac-obrien]

Did you already have had a working example ran successfully in Windows?

Nope, this is my first time trying to build the examples on win10.

I managed to get CMake to find the glfw3 libs with

link_directories("c:/Program Files/glfw3/lib")

But now the actual symbol resolution fails:

main.obj : error LNK2019: unresolved external symbol _wgpu_adapter_request_device referenced in function _main
main.obj : error LNK2019: unresolved external symbol _wgpu_command_encoder_begin_render_pass referenced in function _main
main.obj : error LNK2019: unresolved external symbol _wgpu_create_instance referenced in function _main
...
...
[more unresolved symbol errors...]

And finally:

C:\[...]\wgpu_native.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86'
C:\[...]\hello_triangle.exe : fatal error LNK1120: 20 unresolved externals

So one issue is that CMake generates x86 build files by default, but on x86_64 most Rust users will be using an x86_64 toolchain. So I changed the generator:

examples-native: lib-native $(FFI_DIR)/wgpu.h examples/hello_triangle_c/main.c
    cd examples/hello_triangle_c && \
    $(CREATE_BUILD_DIR) && \
    cd build && cmake -G "Visual Studio 15 2017 Win64" .. && \
    cmake --build .

And here's what we get:

LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library 
wgpu_native.lib(gfx_backend_dx12-3e80684c5f5b68d5.gfx_backend_dx12.id4g60ft-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol D3D12GetDebugInterface referenced in function _ZN16gfx_backend_dx128Instance6create17hf2b6395cb5fc92d8E 
wgpu_native.lib(d3d12-004407183fed6d3e.d3d12.ag28p13b-cgu.0.rcgu.o) : error LNK2001: unresolved external symbol D3D12GetDebugInterface 
wgpu_native.lib(gfx_backend_dx12-3e80684c5f5b68d5.gfx_backend_dx12.id4g60ft-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol DXGIGetDebugInterface1 referenced in function _ZN16gfx_backend_dx128Instance6create17hf2b6395cb5fc92d8E 
wgpu_native.lib(gfx_backend_dx12-3e80684c5f5b68d5.gfx_backend_dx12.id4g60ft-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol CreateDXGIFactory2 referenced in function _ZN16gfx_backend_dx128Instance6create17hf2b6395cb5fc92d8E 
wgpu_native.lib(d3d12-004407183fed6d3e.d3d12.ag28p13b-cgu.0.rcgu.o) : error LNK2001: unresolved external symbol CreateDXGIFactory2 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol WSACleanup referenced in function _ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h56a35f5f14e58a2fE 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol closesocket referenced in function _ZN4core3ptr18real_drop_in_place17h7bf52df4641b6d98E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol freeaddrinfo referenced in function _ZN4core3ptr18real_drop_in_place17h9f088986590caf9aE 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol GetUserProfileDirectoryW referenced in function _ZN3std3env8home_dir17hdcb821269753420cE 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol getpeername referenced in function _ZN3std3net3tcp9TcpStream9peer_addr17hf4d0b58538406952E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol WSAGetLastError referenced in function _ZN3std3net3tcp9TcpStream9peer_addr17hf4d0b58538406952E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol shutdown referenced in function _ZN3std3net3tcp9TcpStream8shutdown17h5272876e42edfdc1E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol recv referenced in function _ZN3std3net3tcp9TcpStream4peek17h3c913790e0d53daeE 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol setsockopt referenced in function _ZN3std3net3tcp9TcpStream11set_nodelay17h33a4ba2e62671094E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol WSARecv referenced in function _ZN58_$LT$std..net..tcp..TcpStream$u20$as$u20$std..io..Read$GT$13read_vectored17h623370091c0648a9E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol send referenced in function _ZN59_$LT$std..net..tcp..TcpStream$u20$as$u20$std..io..Write$GT$5write17h6e9547f401752ba3E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol WSASend referenced in function _ZN59_$LT$std..net..tcp..TcpStream$u20$as$u20$std..io..Write$GT$14write_vectored17h0d076cb2f40bccc3E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol getsockname referenced in function _ZN3std3net3tcp11TcpListener10local_addr17h23ba74fc1e9f3075E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol ioctlsocket referenced in function _ZN3std3net3tcp11TcpListener15set_nonblocking17hfad71654ebc33e95E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol WSAStartup referenced in function _ZN3std4sync4once4Once9call_once28_$u7b$$u7b$closure$u7d$$u7d$17h8ecce79141249397E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol getsockopt referenced in function _ZN3std10sys_common3net10getsockopt17h36f72830b5d483acE 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol getaddrinfo referenced in function _ZN109_$LT$std..sys_common..net..LookupHost$u20$as$u20$core..convert..TryFrom$LT$$LP$$RF$str$C$$u20$u16$RP$$GT$$GT$8try_from17h2f4ab5ef93ea5aafE 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol connect referenced in function _ZN3std10sys_common3net9TcpStream7connect17h2df7e4090acf4f34E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol bind referenced in function _ZN3std10sys_common3net11TcpListener4bind17ha6b85cf97be08c05E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol listen referenced in function _ZN3std10sys_common3net11TcpListener4bind17ha6b85cf97be08c05E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol sendto referenced in function _ZN3std10sys_common3net9UdpSocket7send_to17hdea202204718e9c9E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol WSASocketW referenced in function _ZN3std3sys7windows3net6Socket3new17h0c23627b81823b13E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol select referenced in function _ZN3std3sys7windows3net6Socket15connect_timeout17h4f820c87953707c7E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol accept referenced in function _ZN3std3sys7windows3net6Socket6accept17hc00f640c736d2bb2E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol WSADuplicateSocketW referenced in function _ZN3std3sys7windows3net6Socket9duplicate17h196a895cf5555ee2E 
wgpu_native.lib(std-b5c23ab0516a89db.std.3nac8eiu-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol recvfrom referenced in function _ZN3std3sys7windows3net6Socket20recv_from_with_flags17h4d467731185c87c2E 
wgpu_native.lib(gfx_backend_dx12-3e80684c5f5b68d5.gfx_backend_dx12.id4g60ft-cgu.9.rcgu.o) : error LNK2019: unresolved external symbol D3D12CreateDevice referenced in function _ZN5d3d126device76_$LT$impl$u20$d3d12..com..WeakPtr$LT$winapi..um..d3d12..ID3D12Device$GT$$GT$6create17hac72f9dedc0861c7E 
wgpu_native.lib(gfx_backend_dx12-3e80684c5f5b68d5.gfx_backend_dx12.id4g60ft-cgu.4.rcgu.o) : error LNK2019: unresolved external symbol D3DCompile referenced in function _ZN16gfx_backend_dx126device14compile_shader17h7f958f49f848d3bfE 
wgpu_native.lib(d3d12-004407183fed6d3e.d3d12.ag28p13b-cgu.3.rcgu.o) : error LNK2001: unresolved external symbol D3DCompile 
wgpu_native.lib(d3d12-004407183fed6d3e.d3d12.ag28p13b-cgu.0.rcgu.o) : error LNK2019: unresolved external symbol D3D12SerializeRootSignature referenced in function _ZN5d3d1210descriptor83_$LT$impl$u20$d3d12..com..WeakPtr$LT$winapi..um..d3d12..ID3D12RootSignature$GT$$GT$9serialize17h6cbcf1effc7fc566E 
wgpu_native.lib(backtrace-9bf09026484138e4.backtrace.2l3oit5b-cgu.4.rcgu.o) : error LNK2019: unresolved external symbol SymInitializeW referenced in function _ZN9backtrace12dbghelp_init17h846b2405be6646eaE 
wgpu_native.lib(backtrace-9bf09026484138e4.backtrace.2l3oit5b-cgu.14.rcgu.o) : error LNK2019: unresolved external symbol SymFromAddrW referenced in function _ZN9backtrace9symbolize7dbghelp7resolve17h87c86220145b776bE 
wgpu_native.lib(backtrace-9bf09026484138e4.backtrace.2l3oit5b-cgu.14.rcgu.o) : error LNK2019: unresolved external symbol SymGetLineFromAddrW64 referenced in function _ZN9backtrace9symbolize7dbghelp7resolve17h87c86220145b776bE 
wgpu_native.lib(backtrace-9bf09026484138e4.backtrace.2l3oit5b-cgu.8.rcgu.o) : error LNK2019: unresolved external symbol SymFunctionTableAccess64 referenced in function _ZN9backtrace9backtrace20trace_unsynchronized17he6ede2ba53fdf73fE 
wgpu_native.lib(backtrace-9bf09026484138e4.backtrace.2l3oit5b-cgu.8.rcgu.o) : error LNK2019: unresolved external symbol SymGetModuleBase64 referenced in function _ZN9backtrace9backtrace20trace_unsynchronized17he6ede2ba53fdf73fE 
wgpu_native.lib(backtrace-9bf09026484138e4.backtrace.2l3oit5b-cgu.8.rcgu.o) : error LNK2019: unresolved external symbol StackWalk64 referenced in function _ZN9backtrace9backtrace20trace_unsynchronized17he6ede2ba53fdf73fE 
wgpu_native.lib(winit-cc487f2dd3410a6a.winit.5j1osnef-cgu.5.rcgu.o) : error LNK2019: unresolved external symbol DwmEnableBlurBehindWindow referenced in function _ZN5winit8platform8platform6window4init17h0dce49f12b83a3a0E 
C:\Users\cobrien\src\wgpu\examples\hello_triangle_c\build\Debug\hello_triangle.exe : fatal error LNK1120: 39 unresolved externals 

I'm not sure where to go from here, but I would say there are a couple partial fixes:

1. Specify (or allow the user to specify) the glfw3 library path (and maybe include path?) for Windows
2. Generate 64-bit build files on 64-bit systems

[Timo-DK]

Specify (or allow the user to specify) the glfw3 library path (and maybe include path?) for Windows

I think it is not possible to automatically set it. I have to dig deeper in the CMake documentation. I have found this though: https://cmake.org/cmake/help/latest/variable/CMAKE_MODULE_PATH.html where you are able to specify where to search for on the computer I think at least.

Generate 64-bit build files on 64-bit systems

I think we still need to give the user the option to even build x86, even if the system is x64. Maybe we could add a parameter or some equivalent for CMake. So that whenever you try to build the application, it will take its system architecture, but if you explicitly specify the architecture it is able to override it.

So I changed the generator:

Like I above already mentioned it, but we should not set the -G parameter in the script, because there are many compilers that are able to be used, or it should be a configurable parameter then it should be flexible. Just like automatically setting the architecture and being able to override it, we could do the same for the compiler; taking the default compiler when no argument is passed, otherwise using the passed in argument.

The best option to continue with those issues is to modify the script, but only so it affects Windows users and not the other platforms. I am not sure what the impact for them will be.

I have available time to do research and modify the file with the above points, if not someone is already doing it. If you are, just let me know, then I might be able to help.

And here's what we get:

And that is exactly where I am already stuck for over a week. The unresolved external symbols are coming from the wgpu_native.lib. The static lib is generated by cargo itself but something in the dependencies is not going right on at least Windows.

Edit 1#
I have found the issue about the references in the rust lang repository issues dating back to 2015: rust-lang/rust#26591
I do not completely understand the problem, but will look into it!

[Timo-DK]

Alright I have a working hello_triangle_c, on Windows!

I have traced every missing reference and added the necessary .lib files.
These are the .lib files I had to manually type and include, so the linker knows where to find the code. (except the wgpu_native.lib)

See result:

Doing this manually on Windows would be the hurdle to do for now. However, I have good news, solving this got me a strong motivation to continue pushing. I will try to fix and link this in the Makefile for Windows only, as I assume that Linux and OSX work. I hope today, or at least tomorrow to have the fix, so we can continue doing what we love most: solving problems!

Edit 1
I see I have built a wgpu_native.lib for the feature "Direct3D". I will also test Vulkan for windows and link the necessary lib files.

Source that helped me fix this:
https://www.reddit.com/r/rust/comments/8vnf2h/statically_linking_a_rust_program_for_c/e1pb3lx?utm_source=share&utm_medium=web2x