Tuesday November 16, 2010

[Time] NameMessage
[07:40] pieterh hi folks
[08:43] 15SAA31ZJ Does anybody have an idea how to switch of strict ansi 98 checking?
[08:47] 15SAA31ZJ I checked the makefile for the dialect flags, but there aren't any
[08:57] sustrik 15SAA31ZJ: i think you can get rid of it by turning the -Werror flag off
[08:57] sustrik it will still be reported
[08:57] sustrik but not treated as error anymore
[09:00] 15SAA31ZJ Sorry, I was looking for std=c90 flag, but I now see the std=c99 flag, wiil remove that
[09:01] 15SAA31ZJ Aargh, I still get the msg_store.cpp:253: error: ISO C++ 1998 does not support 'long long' error
[09:10] sustrik try the -Werror thing
[09:11] mikko 15SAA31ZJ: is this with 2.1.0?
[09:11] mikko 15SAA31ZJ: and are you building on mingw32?
[09:13] sustrik mikko: yes, he does
[09:14] 15SAA31ZJ 2.0.1, yes I'm building on mingw
[09:15] mikko hmm, we should allow turning werror off outside the build
[09:16] mikko rather than having to modify the and rebuilding configure
[09:16] sustrik we can turn it of only for mingw, no?
[09:17] sustrik the less manual configuration is needed the better imo
[09:17] mikko yes, we can turn it off
[09:21] mikko sustrik: this is the thing with __int64 being defined as long long in mingw32
[09:21] sustrik mikko: yes
[09:22] sustrik see issue 66 in bug tracker
[09:27] mikko can we not add mingw32 flag -Wno-long-long ?
[09:27] mikko i need to get my mingw32 running
[09:28] mikko and also add mingw32 build for the daily builds
[09:42] sustrik mikko: won't you need a win box for that?
[09:43] mikko sustrik: i can cross compile on linux
[09:44] sustrik ah
[09:46] 15SAA31ZJ I can define a long long var and it builds fine with the same mingw. Why am I getting this problem with zeromq?
[09:47] mikko 15SAA31ZJ: -Werror -pedantic
[09:47] mikko if you add those to your test build it should fail
[09:47] mikko assuming you compile with g++
[09:48] 15SAA31ZJ Ok, I removed -Werror from the makefile and I'm still get the error. Will strip -pedantic as well
[09:49] 15SAA31ZJ Makes no difference
[09:50] mikko 15SAA31ZJ: make sure that it's removed from all makefiles
[09:52] 15SAA31ZJ,
[09:53] mikko 15SAA31ZJ: are you using dist package or git checkout?
[09:55] mikko sustrik: mingw32 is now in daily builds for master
[09:55] mikko i'll make a patch to fix the build
[09:55] sustrik mikko: thanks!
[09:56] 15SAA31ZJ mikko: Thanks!
[09:57] mikko i think the cleanest fix is to define -Wno-long-long for mingw32
[10:02] w00t hello
[10:02] sustrik hi
[10:03] w00t ah, webchat... my employer will frown upon this:\
[10:40] 15SAA31ZJ I don't want to sound more stupid than usual, but why does the compiler complain about a feature that is not part of the C++98 standard if the option to specify that compliance has to be checked has not been specified?
[10:41] mikko 15SAA31ZJ: mingw32 complains because -pedantic is set
[10:41] mikko 15SAA31ZJ: and -Werror converts the warning to error
[10:41] mikko 15SAA31ZJ: i think i got a working fix for master branch
[10:41] 15SAA31ZJ I understand that, but -std=c++98 has not been set...
[10:41] omarkj /join #CouchDB
[10:41] mikko 15SAA31ZJ: -pedantic is
[10:42] omarkj Ups..Sorry about that.
[10:42] mikko 15SAA31ZJ: it defaults to c++98 compliance
[10:43] mikko 15SAA31ZJ: if you want to test the patch, take a checkout of git master and apply
[10:44] mikko i gotta run for a minute
[10:44] 15SAA31ZJ mikko: Ok, so c++98 is the default. This is still GCC, so why does this only affect mingw?
[10:47] mikko 15SAA31ZJ: because mingw32 defines __int64_t as long long
[10:48] 15SAA31ZJ mikko: which isn't valid?
[10:48] mikko 15SAA31ZJ: not for pedantic c++98 compliance
[10:48] mikko it's valid for C but not for C++
[10:48] 15SAA31ZJ mikko: Ok, thanks!
[12:28] 15SAA31ZJ mikko: Sorry for being difficult, but I still don't know how to fix my mingw build...\
[12:29] sustrik the patch doesn't help?
[12:29] sustrik what error are you getting now?
[12:29] mato sustrik: hi
[12:29] sustrik mato: hi
[12:30] mato guys, master on mingw is broken in other ways
[12:30] mato due to __declspec stuff
[12:30] mato I went through this on Sunday, will fix it properly today or tomorrow
[12:30] mato for the __int64 issue all that needs to be done is that mingw builds use -Wno-long-long
[12:31] mato I'll make a separate patch for that shortly
[12:31] sustrik ok
[12:32] 15SAA31ZJ mikko released a patch, which looks like it patches the configure script. Which I don't seem to have when I get the git master.
[12:32] mikko mato: i got it to build (didnt test running)
[12:32] mikko mato: and while cross compiling i still had weird failure -Wno-long-long
[12:32] mikko had to werror=no
[12:32] mato mikko: we can go through it in a bit and sort things out
[12:33] mikko cool
[12:33] mikko i got a few other build related patches as well
[12:34] mikko
[12:35] mikko got a bit carried away
[12:35] mikko lunch time, bbl
[13:04] CIA-20 zeromq2: 03Martin Sustrik 07maint * r152c64f 10/ builds/msvc/libzmq/libzmq.vcproj :
[13:04] CIA-20 zeromq2: FD_SETSIZE defaults to 1024 in MSVC build
[13:04] CIA-20 zeromq2: Signed-off-by: Martin Sustrik <> -
[13:08] 15SAA31ZJ At the end of a build on mingw I get this:
[13:08] 15SAA31ZJ make[2]: *** [libzmq_la-zmq.lo] Error 1
[13:08] 15SAA31ZJ make[2]: Leaving directory `/c/Projects/zeromq-2.0.10/src'
[13:08] 15SAA31ZJ make[1]: *** [all] Error 2
[13:08] 15SAA31ZJ make[1]: Leaving directory `/c/Projects/zeromq-2.0.10/src'
[13:08] 15SAA31ZJ make: *** [all-recursive] Error 1
[13:08] 15SAA31ZJ What does that mean?
[13:09] mato 15SAA31ZJ: It's the ZMQ_EXPORT stuff that's broken
[13:10] mato 15SAA31ZJ: I will fix that, but not immediately (reinstalling Windows VM, etc etc)
[13:10] 15SAA31ZJ mato: Ok, is that the _declspec issue... Thanks
[13:10] mato 15SAA31ZJ: yes.
[13:11] mato 15SAA31ZJ: although I thought it only affected master, but if 2.0.10 is failing that way for you then I guess it affects both.
[13:13] mato 15SAA31ZJ: IIRC a quick but suboptimal fix is to edit the definition of ZMQ_EXPORT in include/zmq.h and include/zmq_util.h
[13:13] mato Where you have:
[13:13] mato # if defined DLL_EXPORT
[13:13] mato # define ZMQ_EXPORT __declspec(dllexport)
[13:13] mato # else
[13:13] mato # define ZMQ_EXPORT __declspec(dllimport)
[13:13] mato # endif
[13:13] mato Change the #else to just define ZMQ_EXPORT to nothing
[13:13] mato that might work, if not optimally
[13:14] mato but it needs to be fixed properly
[13:14] CIA-20 zeromq2: 03Martin Sustrik 07master * rbd0ecf4 10/ builds/msvc/libzmq/libzmq.vcproj :
[13:14] CIA-20 zeromq2: FD_SETSIZE defaults to 1024 in MSVC build
[13:14] CIA-20 zeromq2: Signed-off-by: Martin Sustrik <> -
[13:32] mikko back
[13:39] 15SAA31ZJ mato: Thanks, I will try
[13:48] mato mikko: i'm in the middle of reinstalling my windows vm... once that's done i can start looking at mingw
[13:49] mikko mato: cool, ill fix some ws issues on the patches
[14:06] mikko mato:
[14:06] mikko there
[14:07] mikko reformatted the whitespace errors
[14:07] mikko and changed the mingw32 build to do no-long-long
[14:08] mato will take a look shortly thx
[14:26] mato T3dshw00
[14:26] mato oops
[14:37] 15SAA31ZJ mato: I changed the definition of ZMQ_EXPORT, but I'm still getting the build errors
[14:39] 15SAA31ZJ mato: Oops, looks like I didn't save zmq.h. Rebuilding now
[14:40] 15SAA31ZJ mato: No, still same errors!
[14:45] mato 15SAA31ZJ: Sorry, maybe that's not the whole solution. it was just what I roughly remembered how I made it work on Sunday
[14:45] mato 15SAA31ZJ: I've almost got Windows and all the bits installed, will look into it
[14:46] 15SAA31ZJ mato: Ok, thanks
[15:07] mato mikko: ok, you still here?
[15:10] mikko mato: yes
[15:10] mikko installing centos
[15:10] mato mikko: looking quickly over your patches, have yet to actually test them
[15:10] mato mikko: 0001-0005 looks fine, I'm not sure of any added value in 0006
[15:11] mato mikko: (moving the PGM stuff into a macro)
[15:11] mato mikko: that just hides it...
[15:11] mato mikko: also, re 0004 - removing LIBZMQ_EXTRA_...
[15:11] mikko mato: it's not mandatory if you don't see value
[15:11] mikko the LIBZMQ_EXTRA_LDFLAGS is not used anywhere
[15:12] mikko LIBZMQ_EXTRA_CXXFLAGS is/was used for CFLAGS as well
[15:12] mato mikko: sure, but the EXTRA_XXXFLAGS are there for a reason; when building the perf tests, self tests, devices, etc. you do not need or want to build with all the extra stuff that goes into the EXTRA_XXXFLAGS
[15:13] mikko EXTRA_CXXFLAGS gets appended after CPPFLAGS?
[15:13] mato mikko: the EXTRA flags are there so that we can separate this stuff
[15:13] mikko because that would prevent user from overriding CPPFLAGS for the build
[15:14] mato that's true
[15:14] mikko but i guess it's two-sided sword
[15:14] mato but i'd still like to somehow separate the build flags required for libzmq vs. the build flags required for everything else
[15:15] mikko i can look into that maybe
[15:15] mikko i would like user to be able to override flags with CFLAGS and CPPFLAGS
[15:16] mikko maybe something like not reset the EXTRA_ flags in the beginning of build ?
[15:16] mikko i can look into it
[15:16] mato possibly
[15:16] mikko 0005 is just handy when hacking the builds
[15:17] mato how so?
[15:17] mikko if i got xmlto and asciidoc it always builds the docs
[15:17] mikko which takes a lot more time on my small vm
[15:17] mato oh, that, yes, sorry
[15:17] mato 0005 is fine
[15:18] mikko let's keep the PGM where it is if you find it cleaner
[15:18] mikko but the small part: -if test "x$gnu_compilers" = "xyes" -a "x$pgm_ext" = "xno"; then
[15:18] mikko i think it's clearer if there is pedantic=no werror=no inside the pgm build
[15:19] mikko as those flags are already checked below
[15:19] mato i'm not sure if some obscure platform doesn't need werror=no pedantic=no even for a non-PGM build
[15:20] mikko mato: i agree with that
[15:20] mato sorry, it's been a while since i looked at all that stuff
[15:20] mikko currently the condition at the end is:
[15:20] mikko if test "x$gnu_compilers" = "xyes" -a "x$pgm_ext" = "xno"; then
[15:21] mikko i think we could just set werror="no" and pedantic="no" if pgm is selected
[15:21] mikko and remove -a "x$pgm_ext" = "xno"
[15:21] mato oh, right, sure
[15:21] mato yes, that makes sense
[15:21] mikko so it's aligned with the rest of the build
[15:22] mikko brb
[16:27] mikko mm
[16:27] mikko mato: seen this before /usr/bin/ld: .libs/libzmq_la-txwi.o: relocation R_X86_64_PC32 against `pgm_rs_create' can not be used when making a shared object; recompile with -fPIC
[16:27] mikko i got that if i try to build on centos 5.5 x86_64 from release 2.0.10
[16:28] mikko if i get maint from github and generate cofnigure on the machine things seem to work fine
[16:28] mato mikko: oh, yeah, old and known issue
[16:28] mato mikko: there's some ancient thread on the ML about it
[16:29] mato mikko: I forget exactly what the details are, but I think it boils down to a RHAT gcc bug
[16:29] mato anyhow, I have windows + mingw and friends installed now
[16:29] mato probably won't do much more with it today, tomorrow I'll look at fixing the ZMQ_EXPORT stuff which is breaking the mingw build
[16:30] mato mikko: You actually managed to build 'master' with mingw on Windows, or was that just a cross-build?
[16:30] mikko mato: cross-compile
[16:30] mikko where does it fail?
[16:31] mato it's complicated
[16:31] mato what happens is
[16:31] mato on master you get a mysterious "Error 1" when libtool tries to build deps for zmq.o
[16:31] mikko i had that
[16:31] mato if you run the actual command by hand and discard the >/dev/null libtool is doing you get the actual error
[16:32] mikko changing to werror="no" on mingw32 sorted that issue
[16:32] mato hmm, interesting
[16:32] mato I guess I didn't realise it was just a warning
[16:32] mikko i got the build just stopping without visible error message
[16:32] mato yes, let me dig up the actual error
[16:32] mikko i changed to werror="no" and it build
[16:32] mikko s/build/built/
[16:33] mikko i didn't get the error out even when i ran the command without 2>&1 in the src/ dir
[16:33] mato you can get it
[16:34] mato here's the actual error:
[16:34] mato $ g++ -DHAVE_CONFIG_H -I. -Werror -pedantic -Wall -Wno-long-long -D_REENTRANT -
[16:34] mato D_THREAD_SAFE -g -O2 -MT libzmq_la-zmq.lo -MD -MP -MF .deps/libzmq_la-zmq.Tpo -
[16:34] mato c zmq.cpp -o libzmq_la-zmq.o
[16:34] mato cc1plus.exe: warnings being treated as errors
[16:34] mato zmq.cpp: In function 'void zmq_version(int*, int*, int*)':
[16:34] mato zmq.cpp:63:6: error: 'void zmq_version(int*, int*, int*)' redeclared without dll
[16:34] mato import attribute: previous dllimport ignored
[16:34] mato i'm not quite sure what is happening here
[16:35] mikko signature / implementation defined with different attributes?
[16:35] mato well, here's the way it *should* work on windows:
[16:36] mato If you're building libzmq as a DLL, DLL_EXPORT is defined (libtool does that, and so does the MSVC project)
[16:36] mato then, when you include zmq.h, ZMQ_EXPORT gets defined as __declspec(dllexport)
[16:36] mato this is all fine
[16:36] mato for windows *users* of the API, DLL_EXPORT is not defined, and ZMQ_EXPORT gets defined as __declspec(dllimport)
[16:37] mato but libtool is doing something funny (I presume that step is dependency generation)
[16:37] mato and it breaks
[16:37] mikko i presume i can reproduce this using my cross compile
[16:37] mikko and removing the werror
[16:37] mikko let's see
[16:38] mato I'd assume so
[16:39] mikko daily builds have mingw32 build now as well
[16:39] mikko cross compile
[16:40] mato oh, great
[16:41] mikko
[16:41] mikko this is the first thing that goes south
[16:42] mikko adding the no-long-long patch
[16:47] mikko mato:
[16:47] mikko that is what the cross compilation gives
[16:48] mato yup, thats what i see
[16:48] mato the question is, what to do about it
[16:48] mato turning off -Werror is not a fix, it just hides the problem
[16:49] mikko yes, that is correct
[16:49] mato d'you know much about libtool internals?
[16:49] mato I don't entirely understand what the aim of that compilation actually is
[16:49] mikko the signature is not defined with ZMQ_EXPORT
[16:49] mikko ermm
[16:50] mikko the implementation
[16:50] mikko does it need to match in both?
[16:51] mato see here:\
[16:51] mato
[16:51] mato
[16:53] mato mikko: note that all of this also needs to be done on POSIX platforms; we've just been ignoring it until now
[16:54] mato what I want to do on other platforms is build with -fvisibility=hidden
[16:54] mato and then define ZMQ_EXPORT for the libzmq shared build to set the per-function visibility to default
[16:56] mato mikko: anyway, i'll have to go soon; will you be around tomorrow?
[16:57] mikko mato: yes, most probably will be
[16:58] mikko ill tinker with mingw32 build
[16:58] mato ok, let me know by email if you figure out anything, otherwise i'll continue tomorrow and get it working...
[16:59] mikko sure
[16:59] mikko talk to you tomorrow
[17:00] mato ack; i'm still here, but leaving in 1/2 an hour
[17:35] mikko mato: i got it to build
[17:42] mikko but not yet there
[20:54] oink Hello zmq people. Small question for you: I'm trying to write a 'friendly' cpp class that uses zmq, and find that there are asserts that make this difficult.
[20:55] oink e.g. rc = socket.recv(&msg) ... has a nice rc for errors, but if (stupidly) binding to a non existent host, then kaboom!
[20:56] oink in this case the assert in the zmq_connecter_t constructor, and is correctly noticing that the host does not exist
[20:58] mikko mato: i think i nailed it (at least partially)
[20:59] oink It seems that an application developer is required to ultra-validate any input before sending into zmq - although acceptable, it seems a shame to repeat the validation
[20:59] mikko oink: i think 0MQ is moving away from asserts one by one
[21:00] mikko i remember seeing discussion about this
[21:00] oink thanks, that is comforting to know
[21:17] dcadenas hi guys, I'm an zeromq newbie, can anyone tell me if it lets me see the content of each message without consuming it? I think that other alternatives like rabbitmq don't let doing that
[21:17] mikko dcadenas: you need to consume the message to see the contents
[21:17] cremes dcadenas: no, there is no "peek"
[21:18] dcadenas ah ok thanks