setup appveyor and make it work on windows
daschl opened this issue · 21 comments
do you have concrete plans on supporting windows in the near future?
Since hwloc provides windows binaries, i suppose there should be a rather easy way.
@Trolldemorted yeah I don't have immediate access to a windows box, so any contribution would be very welcome! :)
how can i help?
this is what happens if i add hwloc = "0.3.0" to my dependencies:
Compiling hwloc v0.3.0
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\lib.rs:100:12: 100:21 error: unresolved import `libc::pthread_t`. There is no `pthread_t` in `libc` [E0432]
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\lib.rs:100 use libc::{pthread_t, pid_t};
^~~~~~~~~
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\lib.rs:100:12: 100:21 help: run `rustc --explain E0432` to see a detailed explanation
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\lib.rs:100:23: 100:28 error: unresolved import `libc::pid_t`. There is no `pid_t` in `libc` [E0432]
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\lib.rs:100 use libc::{pthread_t, pid_t};
^~~~~
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\lib.rs:100:23: 100:28 help: run `rustc --explain E0432` to see a detailed explanation
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\ffi.rs:1:48: 1:53 error: unresolved import `libc::pid_t`. There is no `pid_t` in `libc` [E0432]
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\ffi.rs:1 use libc::{c_int, c_uint, c_ulonglong, c_char, pid_t, pthread_t};
^~~~~
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\ffi.rs:1:48: 1:53 help: run `rustc --explain E0432` to see a detailed explanation
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\ffi.rs:1:55: 1:64 error: unresolved import `libc::pthread_t`. There is no `pthread_t` in `libc` [E0432]
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\ffi.rs:1 use libc::{c_int, c_uint, c_ulonglong, c_char, pid_t, pthread_t};
^~~~~~~~~
C:\Users\XXXXX\.cargo\registry\src\github.com-1ecc6299db9ec823\hwloc-0.3.0\src\ffi.rs:1:55: 1:64 help: run `rustc --explain E0432` to see a detailed explanation
error: aborting due to 4 previous errors
error: Could not compile `hwloc`.
To learn more, run the command again with --verbose.
Process finished with exit code 101
Looks like pid_t and pthread_t are not available on windows, I guess next step is to research what to use instead on windows. I wonder if we need some kind of type abstraction over the process and thread id in the library to mask this nicely
ah actually there is #16 open for this. Looking at other libraries it looks like we need to pull in kernel32-sys instead of libc on windows. https://github.com/ruuda/thread-id/blob/master/Cargo.toml does something similar.
After applying this diff, cargo can now successfully build hwloc-rs on windows.
Unfortunately, if i use it in my project the linker failes:
LINK : fatal error LNK1181: input file \"hwloc.lib\"could not be opened.\r\n
I cannot open the inputfile either since i am unable to locate it, so i guess it is missing. Any ideas? Unfortunately my knowledge on rust&cargo is rather basic.
After renaming the hwloc windows binaries libhwloc.a, libhwloc.def, libhwloc.dll.a, libhwloc.exp, libhwloc.la and libhwloc.lib to hwloc.a, hwloc.def, hwloc.dll.a, hwloc.exp, hwloc.la and hwloc.lib and moving them to C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib the walk_tree example compiles, links and runs.
What is the intended workflow? How do i tell cargo/rustc/link.exe where to look for the hwloc binaries, and what their filenames are?
Wow that is very cool! great you see you got it to work. Honestly I don't know how the workflow should look like - I wonder if the library can link to them directly for windows without having to rename them?
this is how rustc calls the linker (newlines added for readability):
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\link.exe"
"/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64"
"/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.14393.0\ucrt\x64"
"/LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.14393.0\um\x64"
"/NOLOGO"
"/NXCOMPAT"
"/LIBPATH:C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib"
"C:\Users\XXXX\repositories\hwloc-rs\target\debug\examples\walk_tree.0.o"
"/OUT:C:\Users\XXXX\repositories\hwloc-rs\target\debug\examples\walk_tree.exe"
"/OPT:REF,ICF"
"/DEBUG"
"/LIBPATH:C:\Users\XXXX\repositories\hwloc-rs\target\debug\deps"
"/LIBPATH:C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib"
"C:\Users\XXXX\repositories\hwloc-rs\target\debug\deps\libhwloc.rlib"
"C:\Users\XXXX\repositories\hwloc-rs\target\debug\deps\liberrno-dd19ca814654318b.rlib"
"C:\Users\XXXX\repositories\hwloc-rs\target\debug\deps\libnum-1fa4854b44bb6a54.rlib"
"C:\Users\XXXX\repositories\hwloc-rs\target\debug\deps\libbitflags-1efefdc447eb53f2.rlib"
"C:\Users\XXXX\repositories\hwloc-rs\target\debug\deps\libkernel32-df86a08647459244.rlib"
"C:\Users\XXXX\repositories\hwloc-rs\target\debug\deps\libwinapi-0889532d327ff4e2.rlib"
"C:\Users\XXXX\repositories\hwloc-rs\target\debug\deps\libnum_iter-50df698bc905252c.rlib"
"C:\Users\XXXX\repositories\hwloc-rs\target\debug\deps\libnum_integer-52fdddf28cd8e924.rlib"
"C:\Users\XXXX\repositories\hwloc-rs\target\debug\deps\libnum_traits-92bb90166cd1857c.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd-a4729905.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libpanic_unwind-a4729905.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libunwind-a4729905.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\liblibc-a4729905.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\librand-a4729905.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcollections-a4729905.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\librustc_unicode-a4729905.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\liballoc-a4729905.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\liballoc_system-a4729905.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcore-a4729905.rlib"
"C:\Users\XXXX\.multirust\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib\libcompiler_builtins-a4729905.rlib"
"libhwloc.lib"
"kernel32.lib"
"ws2_32.lib"
"userenv.lib"
"shell32.lib"
"advapi32.lib"
"msvcrt.lib"
As you can see the linker will expect libhwloc.lib somewhere in the library path, so i copypasted the binaries into it and was happy it worked. How did you tell cargo that you depend on a library with that name (and why is the name different on windows?)? And where does cargo/rustc use my VS installations' libraries? Do they use visual studio's command prompts which setup LIB/LIBPATH environment variables?
@Trolldemorted thank you very much! I'll slice a release as soon as I can with it :)
appveyor is not yet working, we are on it.
edit: we found the error, but since travis is incapable of getting it's shit together we are waiting whether the travis build needs some more love too.
yeah for some reason the travis build is still queued
@Trolldemorted do you want me to do slice a 0.4 release with what we have right now?
i tested it on ubuntu & w10, if it works on mac too then go ahead i'd say 👍
Do you want to support 32bit builds too? We did not bother to test these.
@Trolldemorted certainly not for 0.4 :) I'll run the tests on mac and if it works release 0.4. thanks so much for the work on the windows builds
@Trolldemorted I had to change kernel32-sys to 0.2.1 since cargo reported issues:
$ cargo test
Updating registry `https://github.com/rust-lang/crates.io-index`
error: failed to select a version for `kernel32-sys` (required by `errno`):
all possible versions conflict with previously selected versions of `kernel32-sys`
version 0.2.2 in use by kernel32-sys v0.2.2
possible versions to select: 0.2.1
on which system? macos?
yeah, I wonder that its not failing all the time, since its a cargo dependency mismatch?
@Trolldemorted it would also be cool if at some point you could add a small section for windows to the readme that would be fantastic :)
YAY! appveyor just went green on the badge :) So I'll close out this one and release 0.4.. thanks much again!