[Tor-BSD] Building Tor 0.2.7.x on OpenBSD
attila
attila at stalphonsos.com
Mon Jul 27 11:33:08 EDT 2015
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384
attila <attila at stalphonsos.com> writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA384
>
>
> attila <attila at stalphonsos.com> writes:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA384
>>
>>
>> Pascal Stumpf <Pascal.Stumpf at cubes.de> writes:
>>
>>> On Thu, 23 Jul 2015 16:17:59 -0500, attila wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> 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.
Alright, I've had the weekend to not think about it and coming back
fresh I think I have a slightly better patch for bleeding edge tor
w/libevent2 on OpenBSD-current. My initial reading of things was
subtly wrong in several respects but I don't think my core diagnosis
was wrong. This patch below is a little better that the first one but
in the end it's the same: call evthread_use_pthreads() on Unix. We
ARE always using threads so there's no need to conditionalize it more
than that, it's just the way that using_threads gets set to 1 is a
little convoluted... whatever, not going to fix the world with one
patch, just trying to make it incrementally better:
Patch:
========================================================================
diff --git a/configure.ac b/configure.ac
index 214b7e6..963bb71 100644
- --- a/configure.ac
+++ b/configure.ac
@@ -570,7 +570,12 @@ int x = y(zz);
#else
int x = 1;
#endif
- - ])], [ AC_MSG_RESULT([yes]) ],
+ ])], [ AC_MSG_RESULT([yes])
+ TOR_LIBEVENT_LIBS="-levent_core -levent_extra"
+ if test "$bwin32" = "false"; then
+ TOR_LIBEVENT_LIBS="-levent_pthreads ${TOR_LIBEVENT_LIBS}"
+ fi
+ ],
[ AC_MSG_RESULT([no])
AC_MSG_ERROR([Libevent does not seem new enough to support bufferevents. We require 2.0.13-stable or later]) ] )
fi
diff --git a/src/common/compat_libevent.c b/src/common/compat_libevent.c
index a366b6c..8dfeae2 100644
- --- a/src/common/compat_libevent.c
+++ b/src/common/compat_libevent.c
@@ -208,7 +208,11 @@ tor_libevent_initialize(tor_libevent_cfg *torcfg)
}
#elif defined(__COVERITY__)
/* Avoid a 'dead code' warning below. */
- - using_threads = ! torcfg->disable_iocp;
+ /* N.B. To be clear: This piece of code is always compiled in on
+ * Unix when we are using libevent2. We are always using pthreads
+ * in this case. */
+ using_threads = ! torcfg->disable_iocp; /* disable_iocp defaults to 1 */
+ evthread_use_pthreads();
#endif
if (!using_threads) {
========================================================================
Same instructions for building as above... and, again, this has only
been tested on i386 (uniprocessor at that). I pushed it around
slightly more this time, but still really only a smoke test.
I'm now trying to get the 4 tests that are still failing for me to
stop failing under OpenBSD (i386 still) and in doing so getting to
know the tor codebase better, or at least the test suite...
Pax, -A
- --
http://trac.haqistan.net | attila at stalphonsos.com | 0xE6CC1EDB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Processed by Mailcrypt 3.5.9 <http://mailcrypt.sourceforge.net/>
iQIcBAEBCQAGBQJVtk8UAAoJEJZ30KbmzB7bPP4P/AniyV60HqsHfh27Y2BWFQWB
5qjzGUKz0Oiif459F4TcchL1OigOJNI+n+dNubxVfICC0eRMwbiWO4nKy1Mhl4TD
jRIwBswnuHdvsBJThNwXQpOX9yS5D7VhPxgBbePJGUjnTld9oYpBvcQL8c4PZgNW
bsezSXwWh6BYpcjBjOBwpSovYLfiFKZnngbbL/CU8wYPz/ke3WHmLQIsnYzH8Gkg
LsA6iVebYaJckzTZkVVOqSOaj+1X2hbbwvgfthCH+MZHexWR8IAeTm7NYYh4VWHI
7G+K+DEcApBqfuQaDUoVwoux2EhTXac3PqmUuwW6tdVmVVXw1yVeOEMwhelbm4R9
Zo11GpHwUiAu5bk9fD6lz0PeY+BRM09taVkSdrNzoobVz0E+iw3gap9K9htCFpET
C172eo4X+iL4apzwJCyf/MREBSFfnAqdijQrQlRpFVniDdqOc4glO/9pEXmfMgcm
N6uSW9xwEiaELwTOOlpBEMhgUC/OuVo9oZyM/tmq/sC6UQmACKc8FbpPEbhfMfb7
NgwqrIpRF+ne95qGBSJO72hDW3ZPY+BkcROgUCUq9GyJBqRJg70HfNqgiGM2TTjg
O2z0XDcyoLlILm0n/ARTCjkwc77S8H1HSwY4lk2SdLVG2N5G7D/jWsp8RSWAqB1F
US/8cnjgoL3rnpbxRzLd
=6Yjf
-----END PGP SIGNATURE-----
More information about the Tor-BSD
mailing list