Add windows static compilation support

[jean-airoldie]

Test windows support via the appveyor.yml script.

[jean-airoldie]

Cool, appveyor doesn't seem to clone --recursive. I'll have to fix that.

[jean-airoldie]

Hum seems like zmq.lib is not built on windows for some reason. edit: Nevermind tree only shows directories by default

[jean-airoldie]

Seems like cargo tries to link to zmq.lib but the file is actually called libzmq-v141-mt-sgd-4_3_2.lib.

[hansieodendaal]

This is what happens with dynamic linking in appveyer:

move "%LIBZMQ_LIB_DIR%\libzmq-*lib" "%LIBZMQ_LIB_DIR%\zmq.lib"

With static linking the build script must:

• find and rename libzmq-*lib and set the LIBZMQ_LIB_DIR environment variable. Look at Oblique's code his now closed PR at fn build_static_libzmq() in build.rs. To my mind he was just a bit specific as the files are not consistently named across various C++ compilers.
• find the include files and set the LIBZMQ_INCLUDE_DIR environment variable.
• ensure the dll files are in the path (at least this is true for dynamic linking). It may be sufficient to copy all dll files to the LIBZMQ_LIB_DIR folder. The path must be changed before the compiler is invoked...

[jean-airoldie]

Thanks!

So for static linking I have to renamed the compiled static lib to zmq.lib. I won't assume anything about the file names except that it start with libzmq.

And I'll add another test-crate for testing dynamic linking. I'll open another PR for that and rebase on it.

[hansieodendaal]

great!

[jean-airoldie]

@hansieodendaal I think I got static compilation to work. Now I'm working on dynamic compilation.

However its hard to debug since currently dynamic compilation fails with no error description.

[jean-airoldie]

I give up on supporting windows dynamic compilation for now.

Tell me if this build on you machine and I will merge it.

[oblique]

When I build with debug mode I'm getting unresolved external symbol __imp__CrtDbgReport, I manage to fix this by adding libs.push(Lib::new("msvcrtd", LinkType::Dynamic)) if build_debug is enabled.

When I build with release mode I'm getting:

  = note: build_script_build-1b58b70d24427981.build_script_build.71xmr1qv-cgu.2.rcgu.o : error LNK2019: unresolved external symbol zmq_has referenced in function _ZN18build_script_build4main17h251fc5960d65c130E
          C:\Users\user\Desktop\test\target\release\build\zmq-1b58b70d24427981\build_script_build-1b58b70d24427981.exe : fatal error LNK1120: 1 unresolved externals

This linkage error happens only for rust-zmq/build.rs. If I remove that line it works. Still don't know why.

[jean-airoldie]

@oblique Alright I linked 'msvcrtd' on msvc if build_debug is true. Also I will add CI testing for debug and release mode.

This linkage error happens only for rust-zmq/build.rs. If I remove that line it works. Still don't know why.

I'm not sure I understand what you mean by 'that line'. Do you mean a line in particular or that zmq_has is not properly linked by rust-zmq is built?

[oblique]

I mean this one. As I understood zmq.lib is not linked to the build script of rust-zmq, but only when release mode is used.

[jean-airoldie]

Ok I'll look into. Kinda weird since my CI tests pass for both debug and release builds while links against zmq_version to test.

Did you test compiling rust-zmq using this current WIP branch? Or was it using the latest crates.io release?

[oblique]

Yes. I'm using appveyor branch of zeromq-src-rs and zeromq-src branch of your rust-zmq fork.

I'm running the following in rust-zmq

cargo test --features vendored --release -vv

[jean-airoldie]

I'll try to replicate the error by modifying the rust-zmq's appveyor build since I don't have access to a windows machine.

[oblique]

By removing config.generator("NMake Makefiles") fixes the problem. For some reason /GL- is ignored when nmake is used.

Now I have a new issue: compile_test does not pass. If I disable it, the rest are ok. Again this happens only on release mode.

[oblique]

Ok found the problem with compile_test, I had to point this to release directory.

[jean-airoldie]

I think it should rather point to a cargo env variable such as ZMQ_SYS_OUT.

[jean-airoldie]

I'll remove the NMake generator. Also the build should be reran when profile changes in the zmq-rust buidl script.

[oblique]

ZMQ_SYS_OUT is not defined when the test is compiled. Anyway I will open a PR to @erickt about this.

[jean-airoldie]

I add could OUT_DIR to the ouput of the build. I will be accessible via DEP_ZMQ_OUT env variable. This would make locating the build output fairly straight forward.

edit: Nevermind I understand now, the PROFILE env should be use to determine whether it is a debug or release buid. edit: The PROFILE env var is not availlable when testing, cfg!(debug_assertions) should be used.

[jean-airoldie]

Hum, now that I don't force NMake i get:

= note: LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library

I'll try removing the msvcrtd lib.

edit: Doesn't work either.

[jean-airoldie]

I'll add back the NMake generator and the msvcrtd lib so that it compiles on CI. This way I can continue working on the rust-zmq build.

[oblique]

I think the problem I had with msvcrtd was something else. So I'm ok by removing it. But the nmake is indeed a problem on release mode for me.

What about this: Have an environment variable ZMQ_SRC_DISABLE_NMAKE and do not use nmake in that case.

[jean-airoldie]

Its also a problem for on the CI build so nevermind.

[jean-airoldie]

Alright the CI now passes with both release and debug.

[jean-airoldie]

I'm gonna merge for now since the CI also passes on rust-zmq's end. If anyone experiences trouble with windows building we'll open a separate issue.