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

Fri Jul 24 19:20:04 EDT 2015

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

USE_BUFFEREVENTS seems to be their shorthand for using libevent2.
So if we're using libevent2 it seems we assume we are using threads.
It's just that they are missing the equivalent initialization code
for non-windows platforms, which is what I added, c.f.:
  <http://www.wangafu.net/~nickm/libevent-book/Ref1_libsetup.html>
... the section about halfway down entitled "Locks and threading".

Short summary: You HAVE to call one of the threads initialization
routines if you're going to use threads, under all platforms.  They
just forgot to under Unix.  I think this explains why teor said it
linked for him but crashed: this call was missing.  It doesn't explain
why it works under Linux.  I have some theories on that but I'll let
that be for another day...

This is why I changed the cpp fu in src/common/compat_libevent.c, so
that it logically says

  #if were_using_libevent2 /* and thus, implicitly, threads */
  # if winders
  ...
  # else /* !winders */
  ...
  # endif
  #endif

So after all is said and done I read the situation as: if we're using
libevent2, we must turn on threads, so just add -levent_pthreads to
the list of libraries in the same place I add the other base libevent2
- -l flags.  If pkg-config can do this too then yes, I agree, that's
better.  If -levent_pthreads breaks things under Win32 then this isn't
good enough but I'm not sure what to do there because I've only used
libevent under Unix.

Hope this helps.

>
>> Patch:
>> ========================================================================
>> diff --git a/configure.ac b/configure.ac
>> index 214b7e6..79bd1cc 100644
>> - --- a/configure.ac
>> +++ b/configure.ac
>> @@ -570,7 +570,9 @@ int x = y(zz);
>>  #else
>>  int x = 1;
>>  #endif
>> - -   ])], [ AC_MSG_RESULT([yes]) ],
>> +   ])], [ AC_MSG_RESULT([yes])
>> +       TOR_LIBEVENT_LIBS="-levent_pthreads -levent_core -levent_extra"
>> +   ],
>>        [ 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..b6382c0 100644
>> - --- a/src/common/compat_libevent.c
>> +++ b/src/common/compat_libevent.c
>> @@ -197,7 +197,8 @@ tor_libevent_initialize(tor_libevent_cfg *torcfg)
>>      cfg = event_config_new();
>>      tor_assert(cfg);
>>  
>> - -#if defined(_WIN32) && defined(USE_BUFFEREVENTS)
>> +#if defined(USE_BUFFEREVENTS)
>> +# if defined(_WIN32)
>>      if (! torcfg->disable_iocp) {
>>        evthread_use_windows_threads();
>>        event_config_set_flag(cfg, EVENT_BASE_FLAG_STARTUP_IOCP);
>> @@ -206,6 +207,9 @@ tor_libevent_initialize(tor_libevent_cfg *torcfg)
>>      } else {
>>        using_iocp_bufferevents = 0;
>>      }
>> +# else
>> +    evthread_use_pthreads();
>> +# endif
>
> Not sure why this part is needed though.  Care to explain?
>
>>  #elif defined(__COVERITY__)
>>      /* Avoid a 'dead code' warning below. */
>>      using_threads = ! torcfg->disable_iocp;
>> ======================================================================== 
>> 
>> 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/>
>> 
>> iQIcBAEBCQAGBQJVsVnpAAoJEJZ30KbmzB7bG8gP/itXrkp1lK38YN9ZNgQ9ol68
>> nc6RIMokbvD0NRfoIVt8K5n1zL4taBpFG1YDChH3jNgaW5vf0KfDvfNzzwDK557O
>> GxioI7BrnH4NnAtJDOI0+FrsglfDsu+iWtyKUML/ZW0It34QZjX+2uPnX2O2PH+k
>> C5UcQgLgEZu5ZvWheVrEEKkCg6OV780Rot+jTu5bKhQsWiQZTDIhfnhOunfiipje
>> YCE8sCxi4vqDg+Yca3gT14qFfL31DnwQWLUd/uCwVM1Z5Cwi1Ngqielf4sgnENrV
>> s+YR22Kr5eUSRCf6n61ctu9EOWFblMrRFLkjx0E9sGO9NyLv8lb8aNGN5lmLHaFr
>> q1nwxdin1pFoPxppLcyw75py49/8c5NIZXOht4PT9edEih7AOergjelaIC3BWMlO
>> LfG0fPmm9V4yCZW/L4xJzr9DNwCKNMU5GKi7PVr9Vl4zALAqQ9Sbb8ZzXi9fI5my
>> oXwIel6udgu0l6f0SKncTtodJsa4t8BxHDQ2NYcVXje+7UmAmVuQLKQdH53fZZnj
>> ltYP8n1lHX+mG5Hvn1Se0M/GfTtn0vyjWhxpl5TEXZJLrlDdYm99XwS27G9RyJ2x
>> FgqUUIOZmrLHk6LChRb7fSW05wZE81Rn7Jxh8ODUIuMTrpjZy/UXvavU/NQuCNcW
>> 7ApnPIMNoZsnieURjv1c
>> =db1u
>> -----END PGP SIGNATURE-----
>> 
>> 

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

iQIcBAEBCQAGBQJVssfuAAoJEJZ30KbmzB7b63MQAL9Hw8XTjjxpmKBJmSnCyTzR
GrwAxNY8id15qKgVWgNcV6XH10ugBLLrtlq6jY39RrNpQdovAhWBfBv0/HXjT8Q1
nYEjOfYCI3iaob45GOMRV1TgT3d1Ml0Hi3BnroJ8Bv1fvt1+sxJRBoCG4O08JwIP
WRglGsdpH5vZSm5OLN+pyc5n5h4V4SU49jAXpsX2MNqdEelhsMSGGRFVbvOqQ0Y+
UYOIPkyBFPet/eve3+gAAPVfTUN+QsNB8uYr3mxGDBDz6RVu6MRorH3hhHVVkeL3
/LI0bjeYRfiQjugf2MIuKWX6pf9YEed9pMnaeGHhY7ql4JyPFMRa6JkVFLzMN7Qj
ua5nDVuqmVhA9jTKlNhgEXYheCiAyWJ3GYy37SQQzocFN5X4NfqEJzW2bCtwyBpw
IuRlWRyWfK+s7wVGOEoJcZV9LU0ZRWUS9rRb1PBtleOpaaUB9crBVEzbiRilrmi/
CEDHKn5VvadXoAoAaFFBTup/ZCauwA5f6z7fQrDnXx4KVIe5N9lMg2bLND+MLNuZ
iEhw71PeZbd+dRocKfEMNzhepsHXva5chea6OrBBGYhQCtZ/aTYsVfa0PpQ7tJKV
I6sKf6JwCiXLwCJnPepVQsvs6bwmF+f/aTJBRWdhUpOXpgKu7XZ/atz+hG4uSCiq
UqPDbXjadDejWMDH4nyO
=AP4U
-----END PGP SIGNATURE-----