Tor on Android

[Nick Mathewson]

On Sun, Dec 28, 2008 at 07:24:17PM -0800, Adam Langley wrote:
> On Sun, Dec 28, 2008 at 6:30 PM, Nick Mathewson <nickm at 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