[OTR-dev] Re: [OTR-announce] gaim-otr 2.0.1 is up (BUT DOESN'T DO AUTOCONF!!)

Greg Troxel gdt at ir.bbn.com
Tue Mar 1 18:32:05 EST 2005


  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>



More information about the OTR-dev mailing list