From gdt at ir.bbn.com  Tue Mar  1 12:13:56 2005
From: gdt at ir.bbn.com (Greg Troxel)
Date: 01 Mar 2005 12:13:56 -0500
Subject: [OTR-dev] Re: [OTR-announce] gaim-otr 2.0.1 is up (BUT DOESN'T DO AUTOCONF!!)
In-Reply-To: <20050227194314.GK980@smtp.paip.net>
References: <20050224030245.GL2781@smtp.paip.net>
	<rmi3bvjgguk.fsf@fnord.ir.bbn.com>
	<20050227194314.GK980@smtp.paip.net>
Message-ID: <rmifyzf70h7.fsf@fnord.ir.bbn.com>

Ian Goldberg <ian at cypherpunks.ca> writes:

> As you suspected, the block here was that mingwification was non-trivial
> (unlike for libotr).  What we need is a configure.ac macro for gaim
> which (a) checks that the API version of gaim is compatible with what
> we're expecting, and (b) sets GAIM_PLUGIN_LIBS (or something like that)
> to the libraries you need to use to create a (gtk) gaim plugin.

Taking the view that the autoconf support only needs to be as good, it
isn't necessary to check the api version, since by-hand compiles don't
do that now.  But hints later.

As for b), my configure script sets EXTRA_LIBS to the values needed
for gaim's depdendencies, but doesn't include them.  It should be very
easy to check for mingw and include these libs in a variable
MINGW_LIBS that gets set to "" on all but mingw and EXTRA_LIBS.
Perhaps with a --enable-win32 switch that does this, since it's really
a compiling-for-windows issue, not a mingw issue.

Perhaps:

WIN32_LIBS=""
AC_ARG_ENABLE([win32],
	  AC_HELP_STRING([--enable-win32],
			 [Include libraries needed by dlopend modules.]),
			 WIN32_LIBS=${EXTRA_LIBS},)
AC_SUBST(WIN32_LIBS)

and then add @WIN32_LIBS@ to the link line in Makefile.am

[not tested, but should be close]

It sounds like the headers are needed, so EXTRA_CFLAGS should be in
the CFLAGS line for the plugin.   I think it only worked in my case
since all the pacakges are in the same prefix and the gcrypt -I lines
would also pick up the I wonder if there is any harm in
including the libs in the module in the general case.

> On Linux, that's "".

On NetbSD as well.

>  On mingw, that's "-lgtk-win32-2.0-0 -latk-1.0-0
> -lpango-1.0-0 -lglib-2.0-0 -lgdk-win32-2.0-0 -lgobject-2.0-0 -lgaim".
> [Perhaps separate variables for gtk and for ui-agnostic gaim would be
> better.]  What's going on is that .so files on Linux can resolve symbols
> using the program it's linked into; .dll files on Win32 have to be
> completely resolved themselves.

Thanks - I am not familiar with win32 linking.

> > B) The .la file was not installed, whereas all the native plugins
> > install them.
> 
> ?? Where do they install them?  They're not in /usr/lib/gaim on my
> system.

ls -l /usr/pkg/lib/gaim:

total 8884
-rwxr-xr-x  1 root  wheel     873 Nov 17 10:28 autorecon.la
-rwxr-xr-x  1 root  wheel   84898 Nov 17 10:28 autorecon.so

[and so on]

Hmm, well it is really nice to use libtool.  I wonder if the linux
packages split those out somehow or decline to include them in the
package (kind of like gaim, gaim-dev, and gaim-useless, and putting
them in the third one of the files no one needs).

> I'd *love* for gaim-otr to be autoconfiscated.  If you can supply a
> macro for gaim which does the above, it'll certainly go in for the next
> version.

How does one check the gaim API version?  I couldn't find anything in
the header.  Do you mean just the gaim version number?  If so, that's
checked to be greater than 1.0.3 by the script I sent.  It doesn't
check that it's less than the first incompatible release, but other
than guessing gaim 2 won't be compatible, not sure what to do.
One could also check the version number in the plugin and #error out.
Not the most elegant, but functional.

-- 
        Greg Troxel <gdt at ir.bbn.com>


From ian at cypherpunks.ca  Tue Mar  1 13:40:40 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Tue, 1 Mar 2005 13:40:40 -0500
Subject: [OTR-dev] Re: [OTR-announce] gaim-otr 2.0.1 is up (BUT DOESN'T DO AUTOCONF!!)
In-Reply-To: <rmifyzf70h7.fsf@fnord.ir.bbn.com>
References: <20050224030245.GL2781@smtp.paip.net> <rmi3bvjgguk.fsf@fnord.ir.bbn.com> <20050227194314.GK980@smtp.paip.net> <rmifyzf70h7.fsf@fnord.ir.bbn.com>
Message-ID: <20050301184040.GX980@smtp.paip.net>

On Tue, Mar 01, 2005 at 12:13:56PM -0500, Greg Troxel wrote:
> As for b), my configure script sets EXTRA_LIBS to the values needed
> for gaim's depdendencies, but doesn't include them.  It should be very
> easy to check for mingw and include these libs in a variable
> MINGW_LIBS that gets set to "" on all but mingw and EXTRA_LIBS.
> Perhaps with a --enable-win32 switch that does this, since it's really
> a compiling-for-windows issue, not a mingw issue.

Well, we're getting warmer.  Now libtool is complaining:


/bin/sh ./libtool --mode=link i586-mingw32msvc-gcc -DXTHREADS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/gaim   -DUSING_GTK -DGAIM_PLUGINS -DGAIM_OTR_VERSION=\"2.0.2\" -g -O2   -o gaim-otr.la -rpath /usr/i586-mingw32msvc/lib/gaim -module -avoid-version  -lgcrypt -lgpg-error  -lotr otr-plugin.lo ui.lo dialogs.lo gtk-ui.lo gtk-dialog.lo

*** Warning: This system can not link to static lib archive /usr/lib/gcc/i586-mingw32msvc/3.4.2/../../../../i586-mingw32msvc/lib//libotr.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** But as you try to build a module library, libtool will still create
*** a static module, that should work as long as the dlopening application
*** is linked with the -dlopen flag to resolve symbols at runtime.
libtool: link: warning: undefined symbols not allowed in i586-pc-mingw32msvc shared libraries


It seems to be unwilling to link the static libotr with other objects to
form a dll.  This is libtool being unwilling; i586-mingw32msvc-gcc is
more than happy to do so, as the old Makefile would suggest.

For now, I've autoconfiscated, but left a Makefile.mingw for manual use.
I'd prefer to work out how to get libtool to "play nice", though.

> How does one check the gaim API version?  I couldn't find anything in
> the header.  Do you mean just the gaim version number?  If so, that's
> checked to be greater than 1.0.3 by the script I sent.  It doesn't
> check that it's less than the first incompatible release, but other
> than guessing gaim 2 won't be compatible, not sure what to do.

That's in fact exactly correct.  gaim version numbers follow the "if API
changes incompatibly, change the major version; if API changes
compatibly, change the minor version; if API unchanged, change the
subversion" rule.  So gaim-otr requires gaim >= 1.0.0 and gaim < 2.0.0.

   - Ian


From gdt at ir.bbn.com  Tue Mar  1 18:32:05 2005
From: gdt at ir.bbn.com (Greg Troxel)
Date: 01 Mar 2005 18:32:05 -0500
Subject: [OTR-dev] Re: [OTR-announce] gaim-otr 2.0.1 is up (BUT DOESN'T DO AUTOCONF!!)
In-Reply-To: <20050301184040.GX980@smtp.paip.net>
References: <20050224030245.GL2781@smtp.paip.net>
	<rmi3bvjgguk.fsf@fnord.ir.bbn.com>
	<20050227194314.GK980@smtp.paip.net>
	<rmifyzf70h7.fsf@fnord.ir.bbn.com>
	<20050301184040.GX980@smtp.paip.net>
Message-ID: <rmihdjv2b9m.fsf@fnord.ir.bbn.com>

  It seems to be unwilling to link the static libotr with other objects to
  form a dll.  This is libtool being unwilling; i586-mingw32msvc-gcc is
  more than happy to do so, as the old Makefile would suggest.

Hmm, I don't get this.  On my system libotr is built shared and
static, and the libtool command in Makefile.am says to build both.
How does libtool/mingw choose not to build a dll for libotr?
Is there really a libotr.la?  Does it only have a static lib listed in
it?  It looks like there is a mingw DESTDIR in /usr/i586-mingw32msvc -
am I following correctly?

I wonder if you put $(DESTDIR)/lib/libotr.a as an object, rather than
-lotr.

  For now, I've autoconfiscated, but left a Makefile.mingw for manual use.

Thanks - that sounds like a good plan since we are definitely close.

  I'd prefer to work out how to get libtool to "play nice", though.

Sure, that would be good.  What do you have to do to set up mingw?  Is
it just loading the mingw packages?  Then, I presume you have to build
gaim and gtk etc.   Are there binary packages of those that I can
unpack on my netbsd system to compile otr/gaim-otr against?

  That's in fact exactly correct.  gaim version numbers follow the "if API
  changes incompatibly, change the major version; if API changes
  compatibly, change the minor version; if API unchanged, change the
  subversion" rule.  So gaim-otr requires gaim >= 1.0.0 and gaim < 2.0.0.

I don't know how to express ranges in pkg-config.  Right now, though,
I'd say the real harm from trying to compile against newer gaim
versions is small.  Plus, we'd want to ifdef the code for the
differences, rather than reject them at configure time.

-- 
        Greg Troxel <gdt at ir.bbn.com>


From ian at cypherpunks.ca  Wed Mar  2 09:59:39 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 2 Mar 2005 09:59:39 -0500
Subject: [OTR-dev] Re: [OTR-announce] gaim-otr 2.0.1 is up (BUT DOESN'T DO AUTOCONF!!)
In-Reply-To: <rmihdjv2b9m.fsf@fnord.ir.bbn.com>
References: <20050224030245.GL2781@smtp.paip.net> <rmi3bvjgguk.fsf@fnord.ir.bbn.com> <20050227194314.GK980@smtp.paip.net> <rmifyzf70h7.fsf@fnord.ir.bbn.com> <20050301184040.GX980@smtp.paip.net> <rmihdjv2b9m.fsf@fnord.ir.bbn.com>
Message-ID: <20050302145939.GA980@smtp.paip.net>

On Tue, Mar 01, 2005 at 06:32:05PM -0500, Greg Troxel wrote:
>   It seems to be unwilling to link the static libotr with other objects to
>   form a dll.  This is libtool being unwilling; i586-mingw32msvc-gcc is
>   more than happy to do so, as the old Makefile would suggest.
> 
> Hmm, I don't get this.  On my system libotr is built shared and
> static, and the libtool command in Makefile.am says to build both.

Except that libtool is Very Reluctant to build dlls.  It's got this
crazy aversion to it.  And I'd actually prefer that libotr be statically
linked in to the gaim-otr dll, since otherwise you start to run into
classic Windows "DLL Hell".

A quick perusal of the libtool mailing list implies that they are not
allowing static libs to be linked into dynamic libs quite on purpose.
Their reasoning seems to be: "What if two dynamic libs linked against
two different versions of the same static lib?  They'd each export the
same symbols, which would conflict."  Which is certainly something to
think about, but they give no way to say "no, this isn't (likely) to
happen; do it anyway".

http://lists.gnu.org/archive/html/bug-libtool/2003-05/msg00026.html

> How does libtool/mingw choose not to build a dll for libotr?

DLLs are never built unless you turn off static libs, I'm pretty sure.

> Is there really a libotr.la?  Does it only have a static lib listed in
> it?  It looks like there is a mingw DESTDIR in /usr/i586-mingw32msvc -
> am I following correctly?

All correct.

> I wonder if you put $(DESTDIR)/lib/libotr.a as an object, rather than
> -lotr.

Same problem.

> Sure, that would be good.  What do you have to do to set up mingw?  Is
> it just loading the mingw packages?

Yes; on Debian it was (I think) "apt-get install mingw32".

> Then, I presume you have to build
> gaim and gtk etc.   Are there binary packages of those that I can
> unpack on my netbsd system to compile otr/gaim-otr against?

I just grabbed the relevant dlls from dlldump.com, but arguably,
compiling them from source is "better".  :-)

> I don't know how to express ranges in pkg-config.  Right now, though,
> I'd say the real harm from trying to compile against newer gaim
> versions is small.  Plus, we'd want to ifdef the code for the
> differences, rather than reject them at configure time.

Right, once we know what those differences are.  Putting the check at
configure time means that if gaim-2.0.0 is released tomorrow, gaim-otr
will fail to build with it until someone gets around to seeing what
those incompatible changes are.

   - Ian


From evan.s at dreskin.net  Thu Mar  3 16:37:34 2005
From: evan.s at dreskin.net (Evan Schoenberg)
Date: Thu, 3 Mar 2005 15:37:34 -0600
Subject: [OTR-dev] Bizarre crash... any thoughts?
Message-ID: <e968513f27f0644662b3f02e60f631a7@dreskin.net>

I've got an user who is getting a crash everytime he initiates an OTR 
chat with a particular contact... furthermore, he reports that it 
prompts him to accept the fingerprint every time rather than storing 
it.  Here's the rather sparse crashlog I have:
0   Libgaim                             0x056d6b54 
otrl_context_find_fingerprint + 0x4c
1   Libgaim                             0x056d3510 process_kem + 0x58
2   Libgaim                             0x056d368c process_confresp + 
0x2c

Any thoughts? We're using libottr and gaim-otr 2.0.1.

Thanks is advance :)

--
Evan Schoenberg
http://www.adiumx.com
--------------------------------------
GPG Key: http://evands.penguinmilitia.net/evan_pubkey.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 757 bytes
Desc: not available
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20050303/3e51b26d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20050303/3e51b26d/attachment.pgp>

From ian at cypherpunks.ca  Fri Mar  4 15:20:56 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Fri, 4 Mar 2005 15:20:56 -0500
Subject: [OTR-dev] Bizarre crash... any thoughts?
In-Reply-To: <e968513f27f0644662b3f02e60f631a7@dreskin.net>
References: <e968513f27f0644662b3f02e60f631a7@dreskin.net>
Message-ID: <20050304202056.GE980@smtp.paip.net>

On Thu, Mar 03, 2005 at 03:37:34PM -0600, Evan Schoenberg wrote:
> I've got an user who is getting a crash everytime he initiates an OTR 
> chat with a particular contact... furthermore, he reports that it 
> prompts him to accept the fingerprint every time rather than storing 
> it.  Here's the rather sparse crashlog I have: 
> 0   Libgaim                             0x056d6b54 
> otrl_context_find_fingerprint + 0x4c 
> 1   Libgaim                             0x056d3510 process_kem + 0x58 
> 2   Libgaim                             0x056d368c process_confresp + 
> 0x2c 
> 
> Any thoughts? We're using libottr and gaim-otr 2.0.1. 

Does gaim-otr crash whenever *anyone* talks to this particular contact,
or just your user?  Is this actually gaim, or Adium that's crashing?
What's the other contact using?

   - Ian


From ian at cypherpunks.ca  Thu Mar 31 21:52:21 2005
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Thu, 31 Mar 2005 21:52:21 -0500
Subject: [OTR-dev] Happy Birthday to me.  ;-)
Message-ID: <20050401025221.GV30200@smtp.paip.net>

We just passed 4000 unique IP downloads from the main site.

I finally tracked down the problem that was causing some people using
otrproxy with Trillian to be unable to connect to the AIM network,
sometimes.  [For some it was occsaional; for some it was always; for
some it was never.]  We'll put out 0.3.0 of the proxy with this fix (and
additional UI) next week.

As I mentioned, the bug was only occasional.  Bugs like that are always
hard to figure out.  Top that off with the fact that I don't run
Trillian, or indeed Windows (so all the actual test runs needed to be
done by someone else).

It turns out the bug is in Trillian, and is this:

- When Trillian needs to make a connection to the AIM server via a
  SOCKS5 proxy, it:
  - connects to the proxy
  - sends some SOCKS5 messages back and forth, ending with a message
    from the proxy to Trillian
  - sends AIM protocol messages back and forth, starting with a message
    from the AIM server (via the proxy) to Trillian.
  (This is exactly as it should be.)

- We have verified that if Trillian receives the first AIM message
  very close in time to the last SOCKS5 message (both are coming from
  the proxy to Trillian), Trillian never sees the AIM message, and never
  starts its side of the AIM protocol.

I surmise this is the bug (but of course I've never actually touched a
running Trillian, so who knows):

1. Trillian's SOCKS5 handler is doing something like:

   recv(proxysocket, bigbuf, sizeof(bigbuf), 0);

2. It handles the SOCKS5 message received into bigbuf.

3. When it sees the final SOCKS5 message, it starts the AIM protocol.

4. The AIM protocol also does something like:

   recv(proxysocket, bigbuf, sizeof(bigbuf), 0);
  
So what's the problem?  If the first AIM message has *also* arrived
before Trillian gets to step 1, bigbuf will contain *both* the final
SOCKS5 message, _and_ the first AIM message.  But Trillian apparently
ignores that fact, and eventually times out waiting for it in step 4.
[Or, more likely, in the select() guarding step 4.]

Fix: after processing the final SOCKS5 message in bigbuf in step 2, see
if there's anything left over, and if so, treat it as a message received
in step 4.

So we'll submit this bug report to Trillian tomorrow.  But what can we
do?  For now, we just hardcode a 1 second delay before sending the first
AIM message from the proxy to the client on Win32.  [This fix will be in
0.3.0.]

Many thanks to Michael Wright, Shar van Egmond, and Ian Neal for their
invaluable debugging assistance!

Birthday Bughunting: what a Blast!  ;-)

   - Ian