setup appveyor and make it work on windows

[daschl]

No description provided.

[Trolldemorted]

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.

[daschl]

@Trolldemorted yeah I don't have immediate access to a windows box, so any contribution would be very welcome! :)

[Trolldemorted]

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

[daschl]

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

[daschl]

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.

[Trolldemorted]

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.

[Trolldemorted]

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?

[daschl]

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?

[Trolldemorted]

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]

PR #17 and #18 should take care of this. Tests should pass, at least they do on my local machine.

[daschl]

@Trolldemorted thank you very much! I'll slice a release as soon as I can with it :)

[Trolldemorted]

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.

[daschl]

yeah for some reason the travis build is still queued

[daschl]

@Trolldemorted do you want me to do slice a 0.4 release with what we have right now?

[Trolldemorted]

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.

[daschl]

@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

[daschl]

@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

[Trolldemorted]

on which system? macos?

[daschl]

yeah, I wonder that its not failing all the time, since its a cargo dependency mismatch?

[daschl]

@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 :)

[daschl]

YAY! appveyor just went green on the badge :) So I'll close out this one and release 0.4.. thanks much again!