Tweaking autotools-based buildsystem for W32 compatibility

LRN lrn1986 at
Tue Mar 18 20:43:58 EDT 2014

Hash: SHA1

On 18.03.2014 17:14, Tomasz Wasilczyk wrote:
> W dniu 18.03.2014 13:54, LRN pisze:
>> Anyway, i've successfully built 2.x.y and 3.0.0 on W32 with 
>> autotools, which resulted in a heap of patches on my side (~44 
>> for 3.0.0, ~48 for 2.x.y). How do i go about submitting them? 
>> Usually projects frown upon attaching so many patches to one 
>> bugreport/issue/ticket, but creating 40+ tickets (maybe 10+, if
>> i group patches intelligently; that's still a bit too much, IMO) 
>> seems like a bad move too. Especially since some patches may not 
>> be committable as-is (i'm not always patient enough to come up 
>> with a change that fixes the issue for me and does not break 
>> anything for everyone else).
> I'm glad to hear about your work, because this task was already on 
> my own TODO. I think, you can submit those patches on this list. 
> Creating a bunch of tickets may make it pretty hard to follow.

OK, here goes nothing...
I'll try to provide descriptions here, since patches themselves are
just `diff -u's.

Patches are packed because list moderator, apparently, doesn't approve
of messages larger than 100k, even if it's 100k of patches requested
by the developers.

Should be pretty obvious.
I've made this patch for 2.x.y (actually, ~50% of these patches were
for 2.x.y before i decided to try out 3.0.0 and had to convert them
for 3.0.0), and it made sense there (it still didn't quite work at
runtime, but i never got around to fixing that). Here it's pretty much
useless, since webkit webview uses its own spellchecker (which doesn't
work for me, by the way, but that's another matter entirely) and
gtkspell setup functions are never ever called. Still, if you ever
decide to roll input fields back to gtktextview, this patch may come
in handy.
I've also left alone the abhorrent practice of loading functions from
dlls at runtime, even though in fully-linked build it isn't needed.

Basically, everything includes a header that includes w32-specific
headers, so everything needs the w32 include directory in -I. Since
w32-specific headers have distinctive, unique names, this shouldn't
break anything for other platforms

Check for socket-related headers and include them conditionally in tests.

Added OS_W32 automake conditional, it will be used here and later on
to add W32-specific makefile parts.

Apparently, it needs that. Don't remember the error it gave me without

This patch is useless, since zephyr is not ported anyway. But i didn't
know that when i've made this patch, so here's a patch that removes
the use of non-standard (and non-existent on W32) type caddr_t.

gettimeofday is available in MinGW-w64, do check for it.

'rc' is used for getaddrinfo-related AND for IDN-related code, fix
ifdefs to match that.

Compile libpurple with extra w32 source files.

Adds an implementation of inet_pton() and inet_pton6(). Debatable, but
i like to have real code that i can debug.

Actually, now that i'm re-reading this again, this can be vastly
improved: inet_aton is an alternative to getaddrinfo, so configure
should take that into account. Getaddrinfo check should be fixed to
work on W32 (use the same try-compile-and-link test as for other
network features, see below). This patch is therefore just a fast hack
to allow configure to finish.

ws2_32 uses stdcall convention, autoconf lib checks don't work with
it, you have to use the actual prototype (from the real header) to end
up with a correct function name. Therefore most W32 API checks
(usually for winsock, one of the few parts of W32 API that is
name-compatible with POSIX) need to be compiled and linked with real

This is purely for my own purposes. Since i prefer binaries to be
relocatable, hardcoding absolute ssl cert directory makes no sense,
therefore ssl directory is, in fact, a path relative to the location
where libpurple will be installed. Therefore configure shouldn't fail
when it doesn't exist.

Passing quoted strings via commandline is tricky, and on W32 these are
not used anyway. Also, MSYS mangles paths passed via commandline. So
i've just scrapped all that and put paths into configure.h

Now, for non-W32 platforms that the end of it. But W32 uses runtime
path detection. Now, i extremely dislike non-standard directory
layouts, and i dislike it when configure-set paths are ignored. So
i've added optional XDG-compliant (more or less) path detection code
(actually, it's the other way around - the old code is now optional,
you need to define PURPLE_USE_WINPATHS to enable it, while the default
is XDG).

Anyway, this is how things work now:
CONFIG_${directoryname} macros are set to what configure has
(${datadir}, ${libdir}, etc). These are expanded into real paths all
the way to the end.
PURPLE_${directoryname} macros are platform-dependent:
on W32 they are calls to wpurple_..._dir()
on other platforms they are the same as CONFIG_${directoryname}

At runtime W32 purple will get runtime root directory, then compare
CONFIG_${directoryname} to CONFIG_PREFIX, to see if it starts with a
prefix. If it does, purple will strip the prefix, append the result to
runtime root, and use that. If it doesn't, purple will append it to
runtime root as-is and use that.

Code everywhere now uses PURPLE_*DIR macros, and always keeps in mind
that this macro may be a function call that returns const char *.

Another related change is the use of PNG icons. Now you need to define
the DONT_USE_NICE_PNG_ICON_AS_DEFAULT macro to prevent libpidgin from
using those.

One really bad change it does is that it makes check_libpurple.c
generatable, because it refers to top_builddir.

As noted in earlier patches, SSL_CERTIFICATES_DIR is now allowed to be
relative on W32, and is actually used there.

On W32 libpurple needs W32 libdnsapi, so link to it.

Just to make it compile, code copied from glib examples.

there's signal.h in mingw-w64, but it doesn't do what you think it
does. Ignore it.

Same as 0020-add-w32-files.all.patch earlier.
Also W32 pidgin requires zlib.

Use mingw ansi printf, which is more compatible than MS printf.

These types are needed only if USE_TCL_STUBS

Need to include this header in GG.

I've read somewhere that -no-undefined works only on W32, so adding it
will not affect other platforms. I have not had an opportunity to
confirm that.
Anyway, -no-undefined is always needed for shared libs on W32.

Plugins need to link to libpurple and (sometimes) libpidgin. Therefore
libpurple and libpidgin must be built BEFORE plugins (hence the
SUBDIRS change).
As a side-note, this was even weirder in 2.x.y, where you didn't build
libpidgin at all. I've had to make pidgin.exe export its functions,
crafted a custom import library that links to it, and linked pidgin
plugins to pidgin.exe.

This is from 2.x.y, i'm not sure it's still needed.

Since mingw ansi stdio is used, these defines break everything
horribly. Not sure how MSVC-compatible this will be, needs research.

Since the advent of silent-rules, silencing libtool is absolutely useless.

This is unfinished port to GDbus. Eventually i've had to configure
with --disable-dbus.

I'm not sure how correct this is, but it generates certain files in
srcdir now, since they depend on other files in srcdir. This all
started when the program that generates files failed to find some
headers, and escalated into this patch.

Need zlib for http compression.

Port to GTK+-3.x

Move stuff around, use GObject instead of GtkObject.

Port to modern libpurple

This extension depends on W32 perl, which i don't have.

These files are generated in builddir, point gtk-doc at them.

This is needed to make libpidgin shared, which creates an import
library for it, which allows us to link plugins to it normally
(without this patch each plugin gets its own libpidgin statically
compiled into it; ouch!)

MS printf uses %s for "char *" and %S for "wchar_t *" in printf, but
%s for "wchar_t *" and %S for "char *" in wprintf. MinGW ANSI printf
uses %S for wchar and %s for char, always.
This patch also fixes path handling (does not assume that path only
uses backslashes as separators).

This is a hack (since pidgin.exe is linked to libpidgin, it does not
need to load anything dynamically).

Purely for my convenience (since i did have pidgin-2.x.y built as well).


This is a hack. My build is fully-linked, so this code is not needed.
Also, i'm still not sure why someone thought it was a good idea to put
dlls into separate-from-where-exe-file-is-and-not-normally-in-PATH

Fix keyring linkage (i hoped that secret keyring will be built (i did
compile libsecret), but it wasn't ported), enable wincred keyring in

- -- 
O< ascii ribbon - stop html email! -
Version: GnuPG v1.4.11 (MingW32)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patches.tar.xz
Type: application/octet-stream
Size: 29732 bytes
Desc: not available
URL: <>

More information about the Devel mailing list