[Tor-BSD] Building Tor 0.2.7.x on OpenBSD

attila attila at stalphonsos.com
Fri Jul 24 20:24:30 EDT 2015

Hash: SHA384

attila <attila at stalphonsos.com> writes:

> Hash: SHA384
> Pascal Stumpf <Pascal.Stumpf at cubes.de> writes:
>> On Thu, 23 Jul 2015 16:17:59 -0500, attila wrote:
>>> Hash: SHA384
>>> teor <teor2345 at gmail.com> writes:
>>> >> On 16 Jul 2015, at 05:23 , Michael McConville <mmcconville at mykolab.com> wrote:
>>> >> 
>>> >> The Libevent 2 port splits it into a bunch of different sub-archives,
>>> >> and the Tor configure options for manual library dependencies seem
>>> >> pretty brittle. I tweaked it some and got it to compile, but it crashed
>>> >> at runtime.
>>> I seem to have done slightly better just now, albeit on i386.  The
>>> patch embedded in this email allowed me to build head of line tor
>>> w/libevent2 installed on OpeBSD-current from packages:
>>> Jul 23 16:09:52.635 [notice] Tor v0.2.7.1-alpha-dev (git-aeeb6376aab186fd) (with bufferevents) running on OpenBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.2 and Zlib 1.2.3.
>>> Furthermore it seems to run and build a first circuit with no
>>> problems.  I have not done more than (effectively) this smoke test at
>>> this point.  In fact what's bogging me down is that "gmake test" fails
>>> four times and I'm digging through the tor test suite to try and grok
>>> it in fullness... however, I don't want this grokking to slow anyone
>>> else down who could take this and run with it, so...
>>> This is how I configured tor after pkg_add'ing libevent:
>>>   $ env AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.11 ./autogen.sh
>>>   $ env CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib \
>>>     ./configure --with-ssl-dir=/usr --disable-gcc-hardening \
>>>                 --enable-bufferevents --disable-asciidoc
>>> N.B. I'm still running the 11 July snap, and this is i386, not amd64.
>>> YMMV.  That's not the most recent snap, so...
>> This looks like it could work, but, as I said earlier, it'd really be
>> much much simpler if tor just used pkg-config to find out libevent2's
>> compile and linker flags.
> [At the risk of being accused of top-posting I'll answer both this
> question and the one further down inline in the patch here, since it
> kind of all goes together]
> How do we get pkg-config to spit out -levent_pthreads?  If we can
> easily do that then I agree; I think the answer is that we can't.  It
> might be better to tack on the -levent_pthreads some other way (like
> when we turn on pthreads), but then it isn't clear to me it was
> intended that libevent2 could be turned on without threading.  The
> reason I say this is that the #if defined(_WIN32) block of code in
> tor_libevent_initialize (src/common/compat_libevent.c) that
> initializes the completion port BS under winders unequivocally assumes
> we are using threads.  The original cpp conditional was:
>   #if defined(USE_BUFFEREVENTS) && defined(_WIN32)
>   ... initialize iocp fu and init threads
>   #endif

Sorry for responding to myself, but this is not quite true: it can be
the case that USE_BUFFEREVENTS is on under Win32 and disable_iocp is
non-zero in the config; it looks like it defaults to 1, so then in the
default scenario we don't use threads under Windows if we're using
libevent2.  I'm not sure what the torrc file that ships with e.g. TBB
for windows looks like (investigating), but just as far as tor is
concerned I'm wrong about assuming threads if libevent2.  This makes
the configure.ac part of my patch slightly wrong, regardless.  I'll
take a look at that and pkg-config in more detail if nobody beats me
to it.

> [snip]

Sorry for the confusion.

Pax, -A
- --
http://trac.haqistan.net | attila at stalphonsos.com | 0xE6CC1EDB
Version: GnuPG v1
Comment: Processed by Mailcrypt 3.5.9 <http://mailcrypt.sourceforge.net/>


More information about the Tor-BSD mailing list