From gdt@ir.bbn.com Tue Mar 1 17:13:56 2005 From: gdt@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> <20050227194314.GK980@smtp.paip.net> Message-ID: Ian Goldberg 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 From ian@cypherpunks.ca Tue Mar 1 18:40:40 2005 From: ian@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: References: <20050224030245.GL2781@smtp.paip.net> <20050227194314.GK980@smtp.paip.net> 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@ir.bbn.com Tue Mar 1 23:32:05 2005 From: gdt@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> <20050227194314.GK980@smtp.paip.net> <20050301184040.GX980@smtp.paip.net> Message-ID: 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 From ian@cypherpunks.ca Wed Mar 2 14:59:39 2005 From: ian@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: References: <20050224030245.GL2781@smtp.paip.net> <20050227194314.GK980@smtp.paip.net> <20050301184040.GX980@smtp.paip.net> 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@dreskin.net Thu Mar 3 21:37:34 2005 From: evan.s@dreskin.net (Evan Schoenberg) Date: Thu, 3 Mar 2005 15:37:34 -0600 Subject: [OTR-dev] Bizarre crash... any thoughts? Message-ID: --Apple-Mail-53-582152385 Content-Type: multipart/alternative; boundary=Apple-Mail-52-582152368 --Apple-Mail-52-582152368 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed 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 --Apple-Mail-52-582152368 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII 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 --Apple-Mail-52-582152368-- --Apple-Mail-53-582152385 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQFCJ4OfI5gp6xQhrvcRAmuoAKC4rgv6dcjOuDLJ2bSwlyt646FKPACeMEXk t5agGdy453M4bfduzFp/S3M= =e3xG -----END PGP SIGNATURE----- --Apple-Mail-53-582152385-- From ian@cypherpunks.ca Fri Mar 4 20:20:56 2005 From: ian@cypherpunks.ca (Ian Goldberg) Date: Fri, 4 Mar 2005 15:20:56 -0500 Subject: [OTR-dev] Bizarre crash... any thoughts? In-Reply-To: References: 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