No such luck for me, at least on Linux. I get linker errors when the
bufferevent code is deleted from the Makefile.am.
I'll commit what I have tonight. If someone else can find a way to omit
bufferevent, then that is welcome :-)
On Nov 7, 2011, at 11:58 AM, George Bosilca wrote:
> I might not
I might not get all the technical details here but I can confirm that your
commit (r25453) fixed all my issues. No more warnings, no ssl nor bufferevent.
george.
On Nov 7, 2011, at 12:55 , Ralph Castain wrote:
> I have this properly fixed now - will commit later tonight. In Nathan's
> defens
I have this properly fixed now - will commit later tonight. In Nathan's
defense, it turns out that the same configuration bug found here also exists in
the libevent207 component (the default one we have been using for a long time).
I won't bother fixing it as the commit deletes that component. W
I'm fixing it now - I haven't seen those warnings before, and I've been using
this component for a long time now. But I do see a configure mistake and will
fix it.
On Nov 6, 2011, at 11:25 PM, Nathan T. Hjelm wrote:
> Hmm, I didn't come across that during testing. You are right that we
> should
Hmm, I didn't come across that during testing. You are right that we
should't be compiling with ssl support.
On Mon, 7 Nov 2011 01:17:50 -0500, George Bosilca
wrote:
> This commit introduced quite a few warnings on Mac OS X. A snippet is
> attached below. Btw, why do we need to build buffer even
This commit introduced quite a few warnings on Mac OS X. A snippet is attached
below. Btw, why do we need to build buffer event support in libevent? And why
ssl ...
../../../../../../ompi/opal/mca/event/libevent2013/libevent/bufferevent_openssl.c:
In function 'bio_bufferevent_read':
../../../..
