Unable to build in Windows 2/18/2016

[sunkin351]

I am going to leave a list of unresolved External symbol errors that I encountered while doing a code analysis on the project that would create a *.dll in VS2015...

zmqpp-build-errors.txt

I hope you can get this resolved soon, I love using these bindings... (Note: These errors occur on the latest libzmq from github.)

[sunkin351]

Am I missing something? Or is there something wrong with the copy of zmqpp that I have? Because to my knowledge, there is nothing wrong with libzmq.

EDIT: Retrying with updated repo... EDIT2: Did not work, there are still all kinds of linker errors.

[benjamg]

looks like the stable branch (4.0.8) does need #include for curve but the libznq's development branch (currently 4.2.0) we don't. We could set defines for this as well but like the defines that caused issues for you previously everything in the 4.2 build is subject to be changed without notice.

[hintjens]

In 4.2 we removed the libsodium dependency (it's optional) and made tweetnacl the default layer. I think this is stable now, sorry for the shifts. (It does make building with security rather easier than before.)

On Fri, Feb 19, 2016 at 9:55 AM, Ben Gray notifications@github.com wrote:

looks like the stable branch (4.0.8) does need #include for curve but the libznq's development branch (currently 4.2.0) we don't. We could set defines for this as well but like the defines that caused issues for you previously everything in the 4.2 build is subject to be changed without notice.

— Reply to this email directly or view it on GitHub https://github.com/zeromq/zmqpp/issues/144#issuecomment-186121331.

[sunkin351]

I have no problem with you switching things up with zmq, I am a new user of zmq, I just want to compile these bindings...

EDIT: What can I do in the meantime to make the bindings on my end compile-able?

[sunkin351]

I have waited a while, is there any progress on fixing this?

[benjamg]

I don't have access to a windows machine so haven't actually looked at this. If it's still the issue with curve and you are compiling against the libzmq dev branch (4.2) you can probably remove the include to solve that. If you have other issues attach the output here and I'll try and work through them.

[sunkin351]

Or maybe its because I don't have curve? I just looked at the source for libzmq and the macro for curve isn't defined in MSVC.

[benjamg]

it might be I made a mistake with the way we check for curve, because as far as I understand it it's optional for libzmq and so the fact you don't have it shouldn't stop you compiling.

[dfct]

I was able to build the latest src successfully with VS2015 today as well as replicate the errors you're seeing @sunkin351. You're getting those build errors because you're missing zmq.lib & ws2_32.lib from the linker step. If you head into Project -> Properties -> Additional Dependencies and add those two libs, that will fix the errors and build successfully. You may need to specify a full path to zmq.lib.

[dfct]

@benjamg in exploring building on Windows today, there are two bugs with CMakeLists.txt re: Windows builds.

The line:

    # show all warnings
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -Wextra")

Should be wrapped in a check for the compiler type as those options are not applicable to Microsoft's compilers and throw an error on build:

    1>cl : Command line warning D9002: ignoring unknown option '-std=c++11'
    1>cl : Command line warning D9002: ignoring unknown option '-pedantic'
    1>cl : Command line error D8021: invalid numeric argument '/Wextra'

Second, CMakeLists.txt should add an additional include library for ws2_32 on Windows:

    if (WIN32 AND MSVC)
      target_link_libraries (target "ws2_32.lib")
    endif (WIN32 AND MSVC)

I'm a giant novice with CMake, so please forgive me for winging this with example text rather than submitting a pull request. But, yeah, I was able to build successfully after manually adding ws2_32.lib to the additional library depencies and clearing out the bad flag.

Cheers

[benjamg]

Cheers. My CMake is also pretty poor but it's something I need to work on anyway so I'll look into how that works for checking versions.

[sunkin351]

By zmq.lib, do you mean libzmq.lib? Also, will try again today with adding ws2_32.lib, just curious, I am building for x64, is this lib for x64?

[dfct]

@sunkin351 Yes, apologies, libzmq.lib. And yes, ws2_32.lib is the correct name for 64-bit builds too.

[sunkin351]

Is it recommended that I link against a DLL or a LIB for libzmq?

[dfct]

@sunkin351 I can't speak for recommendations, but I can mention that if you look to use static you'll need to additionally define ZMQ_STATIC. I did have that working in my Windows builds but later settled on dynamic, myself. Apologies, I don't have an example to point you to other than the Google.

[sunkin351]

Will the compiler automatically consume one dll into the other?

[dfct]

No, if you build ZMQ as a DLL and ZMQPP as a DLL, you'll need to have both DLLs for your project.

[sunkin351]

Is there a way to do it manually? EDIT: No, there doesn't appear to be.

[sunkin351]

Is there a way to link a DLL to a lib?

[sunkin351]

Otherwise This issue is solved. Thanks.

[markns]

@ianbannerman Is adding the Ws2_32.lib link the fix for the missing netinet/in.h header in zap_request.cpp? I'm asking because I've been following your instructions to compile the project under windows, but still missing this header. Coming over to C++ from NetMQ (C#) so rather a steep learning curve going on here at the moment!

[dfct]

@markbarks sorry for the delay getting back to you. Linking or not linking against ws3_32.lib will be unrelated to any trouble with netinet/in.h missing. To my knowledge, the linking step takes place well after processing various include header files.

Not sure what 'missing' means from the context, though. Can you share the error you're seeing?

[markns]

Hi @ianbannerman, thanks for getting back to me. I was unable to compile the zap_request.cpp file because the htobe32 function was not found due to the missing netinet/in.h. I ended up simply including the portable_endian.h header instead, which allowed me to compile and start testing things out.