[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 12:13:56 EST 2005


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>



More information about the OTR-dev mailing list