ZeroMq IRC Log

Tuesday November 16, 2010

[Time] Name	Message
[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 configure.in 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	Makefile.am, Makefile.in?
[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 https://gist.github.com/28a725c30a6d0110e407
[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	http://valokuva.org/~mikko/b/
[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 <sustrik@250bpm.com> - http://bit.ly/bcchqf
[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 <sustrik@250bpm.com> - http://bit.ly/bYT47b
[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: http://valokuva.org/~mikko/b/
[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	https://gist.github.com/ea5b88352f61c26758b2
[16:41] mikko	this is the first thing that goes south
[16:42] mikko	adding the no-long-long patch
[16:47] mikko	mato: https://gist.github.com/ea5b88352f61c26758b2#comments
[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	http://msdn.microsoft.com/en-us/library/9h658af8%28v=VS.80%29.aspx
[16:51] mato	http://msdn.microsoft.com/en-us/library/a90k134d%28VS.80%29.aspx
[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