On Sat, Jul 2, 2011 at 3:33 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > Package: libevent-dev > Version: 2.0.12-stable-1 > Severity: important > Justification: beanstalkd ftbfs > Files: /usr/include/event2/util.h > > Hi, > > Trying to build beanstalkd, I get: > > | gcc -DHAVE_CONFIG_H -I. -g -O2 -Wall -Werror -I/usr/include -c -o > tube.o tube.c > | In file included from /usr/include/event2/event.h:48:0, > | from /usr/include/event.h:192, > | from conn.h:23, > | from prot.h:22, > | from tube.c:25: > | /usr/include/stdio.h:417:12: error: expected identifier or ‘(’ before ‘void’ > | /usr/include/stdio.h:417:12: error: expected ‘)’ before numeric constant > | make[2]: *** [tube.o] Error 1 > > That line in stdio.h defines dprintf(), which is used by beanstalkd > for a totally unrelated purpose (#define dprintf(x) (void) 0). So far > that had not been a problem because until POSIX.1-2008, dprintf was in > the application namespace and POSIX implementations were not allowed to > step on that. > > Indeed, glibc does not define dprintf unless someone has requested > > #define _XOPEN_SOURCE 700 > > or "#define _GNU_SOURCE" or similar (see feature_test_macros(7)). > Unfortunately libevent's util.h defines _GNU_SOURCE, meaning > applications using it have no reliable guarantees about what function > names are available for their own use. > > Also relevant is that POSIX only guarantees that defining feature test > macros will work if it's done before the very first #include of a > system header. So ideally this would be the application's > responsibility. > > Luckily util.h already has ifdefs to gracefully cope even with systems > without any netdb.h at all.
Unfortunately, it's not so graceful at all: the #ifdefs define constants and structures based on the values and layouts associated with the getaddrinfo() interface. (At least, if I recall correctly, that's what Libevent is up to here.) In other words, the libevent EAI_X values are the same as the system EAI values... but if the header sometimes defines its own values (when the user hasn't set GNU_SOURCE) and sometimes doesn't, there will be a mismatch between the system values and Libevent's values, and code that doesn't define the right options will break. We could say, "Libevent should always use its own evutil_addrinfo, and its own EVUTIL_EAI codes". That would break ABI compatibility, though, and I'd rather wait for 2.1 to do that. > I think the best thing to do would be to > allow the application to define _GNU_SOURCE and take advantage of the > additional error numbers opportunistically, or maybe even something > like > > #ifndef _GNU_SOURCE > #warning "please define _GNU_SOURCE for full functionality" > #endif > > There is arguably also a bug in beanstalkd here --- friendly programs > do not rely on outdated versions of POSIX. But that's a less > important bug, so let's deal with this one first. :) I'd definitely like help working on and testing a patch for Libevent to fix this. It's not something I can comfortably put into mainline Libevent the 2.0 (stable) series because of the ABI-breaking issue and because of the possibility of breaking other code, but I'd love to see it fixed in 2.1. > Thanks for reading, and hope that helps. > > Regards, > Jonathan *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
