Windows shared DLL build

Hello,

when building ZMQPP on Windows via Hunter (or trying to do that via cmake from the head version), it appears that for the shared version:

a.) no symbols are exported at all (e.g. no __declspec(dllexport) is seen anywhere in the source) - server
b.) no symbol import library is generated (e.g. no __declspec(dllimport) is seen anywhere in the source) - client

Am I missing something or is there something else to make shared .DLLs working on Windows?
Thanks,

I too have this problem. I wish it resolved so that I may continue testing. I am sure there are probably several others besides us. The main reason I need it is because i am not able to use both the static and dynamic versions of the C/C++ runtime library at once. So I have chosen dynamic. I do not trust myself to correctly alter zmqpp to allow dynamic linking, therefore, we need help.

It looks like there is some work done by @tatraian on this https://github.com/tatraian/zmqpp, however I don't know what the state of that is and I don't have a Windows based development environment right now.

Yes, I work on it. Since at my workplace this problem has been resolved with static build (as I know) I have to fix this at home.

The patch contains two parts and this makes merging more hard.

I used zmqpp through hunter (https://github.com/ruslo/hunter). To be compiled with hunter I had to modify the CMakeLists.txt. I rewrote the target creation and it now generates Config files and ZeroMQ comes through hunter.

After that I did the exportation. Currently I used self made export header but CMake supports this (GenerateExportHeader) so I wanna to replace it similar to this example:
https://github.com/forexample/package-example/blob/cf2ea1d6a209fb9eca2ab83fdd0ac15fe4d3e807/Foo/CMakeLists.txt#L44-L46

Most classes are exportable except crypt classes and the extension actor's classes since it contains a class static context variable so these code must be refactored a bit for Windows export.

In the next week I try to remake the whole export stuff independently from hunter, but please someone who build this project on windows tell me how to compile zmqpp together with zeromq.

For me, I pretty much compile zmqpp and libzmq separate. If there is an OK way to compile them together on windows, i would love to know.

Also, might i suggest you copy the compiler logic found in zmq.h? specifically:

#if defined _WIN32
#   if defined ZMQ_STATIC
#       define ZMQ_EXPORT
#   elif defined DLL_EXPORT
#       define ZMQ_EXPORT __declspec(dllexport)
#   else
#       define ZMQ_EXPORT __declspec(dllimport)
#   endif
#else
#   if defined __SUNPRO_C  || defined __SUNPRO_CC
#       define ZMQ_EXPORT __global
#   elif (defined __GNUC__ && __GNUC__ >= 4) || defined __INTEL_COMPILER
#       define ZMQ_EXPORT __attribute__ ((visibility("default")))
#   else
#       define ZMQ_EXPORT
#   endif
#endif

But you know what? I would love it even more if someone could tell me how to link both .lib's and .dll's to the same application at the same time.

EDIT: Me being so impatient, I decided to try my hand at manually adding in the import/export code based on the preprocessor above. I have it working as far as I can tell. Will update soon on how it goes on compiling a project with this.

apparently, I missed something important in socket.hpp and poller.hpp because there are still 2 missing symbols. Both are static class members. Otherwise, I have done it.

EDIT: Now that I look at this, there is absolutely no reference to these variables anywhere in my code. I have no idea why my application would ever need them... I will let you people figure this out.

You can use the latest version with hunter (for testing). The patched hunter and zmqpp codes can be found here:
https://github.com/tatraian/hunter/releases/tag/zmqpp_export_test1
and here:
https://github.com/tatraian/zmqpp/tree/4.1.2-hunter

Currently (I don't know why) it doesn't use Static interface definitions -> static link doesn't work at all...
I tested only a few functions (I created context, socket and get the version...). So much more test required.
Some classes are missing
Several build warnings

I did a direct modification of the existing zmqpp code and I almost have it working all the way. Could you help me with the static member variables in poller.hpp and socket.hpp? My application needs access to them for reasons that I cannot discern, and I am unable to export them.

My application needs access to them for reasons that I cannot discern.

These variables represents flags, and are (also) used internaly by zmqpp as
default parameter value. This is probably why your application needs to
access
them even though you don't use them directly.

As for exporting them, I don't know as I am mostly using Linux. I would
have guessed that exporting the whole class would export its static
variable.

On Sun, May 1, 2016 at 11:43 PM, sunkin351 notifications@github.com wrote:

I did a direct modification of the existing zmqpp code and I almost have
it working all the way. Could you help me with the static member variables
in poller.hpp and socket.hpp? My application needs access to them for
reasons that I cannot discern, and I am unable to export them.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#151 (comment)

Kapp Arnaud - Xaqq

I guess this is why libzmq has its const data members as macro's, to overcome this predicament.

Just to have your input to how you want this to look, do you think it would be alright if I changed these static const variables to macro's?

I want to advice that you wrote. This evening I had time to test the yesterday commits. Could someone tell me how has to create exception on Windwos since std::runtime_error is not dll exported class... I get several link warning on this. And socket example code crashes at socket's.send function.

Um... I can barely understand what you wrote in that last comment, could you rephrase?

Just to have your input to how you want this to look, do you think it
would be alright if I changed these static const variables to macro's?

Sadly I think it would not be correct. Those variables are part of the
public API so they cannot be removed. The problem with macros is that they
don't respect namespace boundaries.

A replacement that could work, at least on some compilers is to use a
constexpr variable. (see

zmqpp/src/zmqpp/auth.hpp

Line 163 in f0fd690

constexpr static const char * const zap_endpoint_ = "inproc://zeromq.zap.01";

).
But that doesn't seem to work well enough on Windows yet.

It should be possible to get it to work with static class variable though.
I read this SO post:
http://stackoverflow.com/questions/8654327/use-static-class-variable-function-across-dlls

Can you push on your fork so we can take a look?

On Mon, May 2, 2016 at 10:39 PM, sunkin351 notifications@github.com wrote:

Um... I can barely understand what you wrote in that last comment, could
you rephrase?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#151 (comment)

Kapp Arnaud - Xaqq

My problem is that ZMQPP exports their exceptions into dll. But all exceptions inherit from std::runtime_error, which is not exported (by Microsoft). So ZMQPP exported exception types base on not exported type.

Anyway, static const int variables cause link time error or run time error at you?

Link time error.

Also, I have no problem linking to your exception classes. Not even a warning on compile time. Just the static const variables.

EDIT: Then again, i probably wouldnt be able to tell with the 2000+ other warnings that come up during compile of this library, whether it be static or dynamic. Most of them about data structure padding.

Can we modify the library so that these variables are only used inside the library? (Unless you want to write useless functions to return these, which IMO is not a good style for what we are using these variables for.)

Hello,

Theses variable are mostly supposed to be used by library user. They
represent how to poll the socket/fd.

user code would look like:
zmqpp::socket s(ctx, zmqpp::socket_type::pair);
zmqpp::poller p;
p.add(s, zmqpp::poller::poll_out);

So the variables need to be resolvable as they are part of the public API
of zmqpp.
However, I don't understand why it wouldn't work to export those variables.

Regarding @tatraian problem with exception, I can't help, sorry. It looks
like both of
you have complementing problems and solutions regarding this though.

https://github.com/tatraian*

On Tue, May 3, 2016 at 9:18 PM, sunkin351 notifications@github.com wrote:

Can we modify the library so that these variables are only used inside the
library? (Unless you want to write useless functions to return these, which
IMO is not a good style for what we are using these variables for.)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#151 (comment)

Kapp Arnaud - Xaqq

Mine would break your api, but I dont want to stray from your repository due to the active support i would lose if i did. There has to be a way to fix this, but due to what I have read throughout the internet about this, it doesn't seem possible without moving the variables elsewhere. If they were just static, this would probably work. But because they are const as well, this just isn't happening.

So I pose this question to you, will you support dynamic linking in windows, or no?

See PR: #156 for details

I take that as a resounding yes. thanks.

This should be solved via #156