I for one am not familiar with the arcane art that is autoconf, nor have I ever 
built static zeromq libraries with mingw, but you can try the cmake build 
system that I have seen in the current libzmq on github. CMake on windows 
features a GUI and will let you select the toolchain on startup (you'd go for 
MinGW), make sure the BUILD_SHARED_LIBS cmake variable is set to off and cmake 
ought to create a Makefile for mingw to create static libraries.

At least that's how it is supposed to work as per cmake.

Addendum: Now that I skimmed the CMakeLists.txt I see that libzmq is explicitly 
forced to be built as a shared library - is there a reason for this?

Regards
Stefan

[1] https://github.com/zeromq/libzmq/blob/master/CMakeLists.txt#L267

On Dec 4, 2012, at 8:19 PM, Whit Armstrong 
<[email protected]<mailto:[email protected]>>
 wrote:

I never got that far, the DevKit version of mingw complains about being unable 
to generate static libs.  I never got beyond that.

I'm willing to try again if someone with some autoconf/Makefile expertise can 
help.

-Whit



On Tue, Dec 4, 2012 at 2:08 PM, Stefan Radomski 
<[email protected]<mailto:[email protected]>>
 wrote:
I guess the simply setting ZMQ_EXPORT to the empty string, as suggested below, 
will not solve the build issues with static libraries for mingw?


On Dec 4, 2012, at 4:32 PM, Whit Armstrong 
<[email protected]<mailto:[email protected]>> wrote:

It would be particularly helpful if static compile would work for mingw as well.

Right now, it's a blocker for the rzmq windows package.

http://cran.r-project.org/web/packages/rzmq/index.html

-Whit



On Tue, Dec 4, 2012 at 9:36 AM, Stefan Radomski 
<[email protected]<mailto:[email protected]>>
 wrote:
Hi again,

we are compiling static binaries of zeromq and link them into our executables. 
On windows, that means that I always open up zmq.h and zmq_utils.h to edit the 
part with regard to DSO symbol visibility as follows:

#ifndef ZMQ_STATIC
#if defined _WIN32
#   if 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
#else
#define ZMQ_EXPORT
#endif

then adapt the build type in the Visual Studio project and pass ZMQ_STATIC as a 
preprocessor flag. The issue popped up on this list earlier as well [1][2]. The 
question is, whether you'd want the ZMQ_STATIC handling contributed to the 
master branch or is there another supported approach I missed? I cannot see how 
to make a test-case for this one though.

Regards
Stefan

[1] http://lists.zeromq.org/pipermail/zeromq-dev/2011-September/013150.html
[2] 
http://grokbase.com/t/zeromq/zeromq-dev/1166bfmzt6/how-to-make-it-easier-to-compile-static-lib-under-windows-dll-export-in-zmq-h

_______________________________________________
zeromq-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


_______________________________________________
zeromq-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


_______________________________________________
zeromq-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to