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

[attila]

-----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.

> [snip]

Sorry for the confusion.

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/>

iQIcBAEBCQAGBQJVstcbAAoJEJZ30KbmzB7bViIP/Al57eAiKOiToZ1sDSz8dYcn
f064y70URZoWfqjG0+qxzVarlU6F/3FMvfzaNKKA2MKURQoYxcqX3GCKGpzwFW9T
aXx7tJTFZ1UiVP2j80xFIqJV3+bfP6EP7KaVFa4KVtoVCN1WMN60HFPvcMhgC2Wy
D9AAHWUE1qNXFfTpVpgnvmZ67h1akyXESCQqHepa8nmJVOeBKEBEBSQLNiTgAK79
EhrAa94E5M0kxUYqfqqYOBXRjBEJ1w+nYMpIsPtlTAQ56jz1Om/2yDDI4eNIinAu
4LwU1YvdOg6m+034ZLPu+4tbBMEexr3ueYkCTZgcItTtLBOo51hCpoFZaP8umabq
yyGkWVNJSQdVRkhhAZIDyg+5XQ6RxYZjC5HcGDpnWn80Zxmm19n5f43BJxl0zJ37
OS96j0/6whbikeJoRKDZ6Jodqy/dyQqOGUYt09SRJ0LeYwzHKuqq8TDkoy4adzTL
FWi0GnkzLjrgp4ZmKk/wnTaLadICWCgEUnTLLb6z+uv7udZq0F/ZcxzcMkvhhrO1
5mHD9JcAhQiuJb9+Z5FeTE4VryVUzj3LgfvyyxJnaTPcAgc5lps59fNc7tk5hDTf
r78A79xZfGx+rwCvA991Fp+YvUcKb8Qtmy0r9aAp1PbJNp2H8mAbAuCndyVyCPJc
8lJaJ/9ctGlpoIeswOPg
=9zC2
-----END PGP SIGNATURE-----