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. 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. :)
Thanks for reading, and hope that helps.
Regards,
Jonathan
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
