Windows binary is outdated
alexolog opened this issue · comments
Can we have a Windows binary for version 0.20 please?
Sure, done :)
https://eion.robbmob.com/xmpp-carbons/
Eion, can you set some sort of automated nightly build system for all the plugins you provide Windows binaries for?
How does Pidgin do it? Is there a template for using one of the CI/CD platforms that is free for open source projects? Not sure if it's possible to set up cross compilation in such an environment.
We build Pidgin manually too, although @rwgrim is trying to solve that. For example, I built 2.13.0 once the signing cert came through.
I got this to build on an Appveyor Ubuntu box, mostly for uploading coverage results of the tests.
But I chose Appveyor because they originally started out, and still have, Windows boxes. So I hope I can get it to build there soon. I'm pretty sure they also build pull requests, if anyone wants to play around with the .appveyor.yaml on the dev branch...
Have you looked into cross-compiling from Linux?
Well, I thought it would be useful if the tests run on Windows, plus the guide sounds scary: https://developer.pidgin.im/wiki/BuildingWinPidgin (download this, compile from source that, ... doesn't make it sounds like it's that well suited for automating it, but I must admit I didn't actually check if I can get all the dependencies through the package manager).
The Appveyor Windows machines sound pretty well suited for compiling stuff already too: https://www.appveyor.com/docs/windows-images-software/
But if I hear you right you're saying it's still easier on Linux, so I might just try that.
Okay, I did try and this is how far I got:
vagrant@ubuntu-bionic:/vagrant$ make clean
rm -rf ./build
vagrant@ubuntu-bionic:/vagrant$ make win
mkdir -p build
x86_64-w64-mingw32-gcc-win32 -std=c11 -Wall -g -Wstrict-overflow -D_XOPEN_SOURCE=700 -D_BSD_SOURCE -D_DEFAULT_SOURCE -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libpurple -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libxml2 -I./headers/jabber -I/usr/i686-w64-mingw32/include/ -fPIC -shared -DPURPLE_PLUGINS -c ./src/carbons.c -o build/carbons.o
In file included from /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:9:0,
from /usr/include/glib-2.0/glib/gtypes.h:32,
from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from ./src/carbons.c:20:
/usr/include/glib-2.0/glib/gtypes.h: In function ‘_GLIB_CHECKED_ADD_U64’:
/usr/include/glib-2.0/glib/gmacros.h:241:53: error: size of array ‘_GStaticAssertCompileTimeAssertion_0’ is negative
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
^
/usr/include/glib-2.0/glib/gmacros.h:238:47: note: in definition of macro ‘G_PASTE_ARGS’
#define G_PASTE_ARGS(identifier1,identifier2) identifier1 ## identifier2
^~~~~~~~~~~
/usr/include/glib-2.0/glib/gmacros.h:241:44: note: in expansion of macro ‘G_PASTE’
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
^~~~~~~
/usr/include/glib-2.0/glib/gtypes.h:423:3: note: in expansion of macro ‘G_STATIC_ASSERT’
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
^~~~~~~~~~~~~~~
In file included from /usr/include/libxml2/libxml/parser.h:810:0,
from ./headers/jabber/jabber.h:59,
from ./headers/jabber/iq.h:35,
from ./src/carbons.c:27:
/usr/include/libxml2/libxml/encoding.h: At top level:
/usr/include/libxml2/libxml/encoding.h:28:10: fatal error: iconv.h: No such file or directory
#include <iconv.h>
^~~~~~~~~
compilation terminated.
Makefile:66: recipe for target 'build/carbons.o' failed
make: *** [build/carbons.o] Error 1
I set CC to the mingw compiler and added the include dir to the headers when compiling. Not sure how to proceed.
You should now be able to download the latest build from the CI page under the artifacts tab, like here: https://ci.appveyor.com/project/gkdr/carbons/builds/23518864/artifacts
I must admit I didn't test if the Windows version actually works yet but it did when I compiled it myself so I don't see why it shouldn't.
Now just probably set up something that pushed a tagged release to GitHub and I can finally close this.
uh the automated release pushing doesn't seem to work yet and the 2 builds at the same time for both branches and the tag made the (last) build fail, marking the build for this commit is failed. maybe i'll figure this out someday, or switch away from appveyor. don't remember why i picked that in the first place anyway.
@Neustradamus the build does work, i just have to manually download the binaries. the part that fails is the automated push to github. to avoid further confusion, i'll close this and might make a new issue. probably not worth the effort though.