On Sun, Dec 28, 2008 at 07:24:17PM -0800, Adam Langley wrote: > On Sun, Dec 28, 2008 at 6:30 PM, Nick Mathewson <ni...@freehaven.net> wrote: > > Hm. Libevent should be made to detect this. Ordinarily, fd_mask is > > defined in sys/select.h or something it includes. Can you grep around > > a little in the Android headers to make sure it's not defined > > anywhere? If it isn't, we can probably define it to long without > > hurting anything, so long as we define NFDBITS to match. > > It's not defined. This is probably a mistake on bionic's part since, > from reading around, fd_mask is POSIX. Rather than change libevent, > probably bionic should be changed. I'll look at doing that tomorrow.
If so, bionic should be changed. But sometimes writing portable software means building on platforms that do silly things. If the broken bionics are widespread, libevent could cope pretty easily, since it only uses fd_mask for sizeof(fd_mask) which it uses to calculate how many bytes to allocate for an fd_set. If the code instead just always allocated a multiple of sizeof(long) bits per fd_set, it would be more concise anyway, and not significantly less correct. > Also, android has a config include file which is included in all > compiles. This might well be a mistake as it defines HAVE_SYS_SOCKET_H > and that's pretty rude. Yeah. If you want to do something like this, the usual trick is to post-process the config.h so that all the macros now start with a common prefix that won't conflict with the regular autoconf macros. For an example, recent libevent versions should do it right; old ones had the same problem as Android. [...] > With a little investigate, the issue is in the agcc script. I had it > add the libevent directory as an include path, but it put's -I options > last on the resulting command line. Thus libevent's log.h was getting > picked up. I've attached a version which collects -I arguments and > puts them first on the gcc command line It would be neat if you sent the agcc patch upstream. :) [...] > and this allows tip-of-SVN to > build with these modifications: Interesting! Both were clearly errors in the source. Both patches are now applied. If you're feeling brave, try configuring Tor with the --enable-gcc-warnings option: it will warn about other compilation issues that we might want to care about. -- Nick