Developing on win32 is a nightmare and we rely on far too many sources for all the DLLs we need. We should setup a cross compile environment based on mingw so that anyone can just follow some simple (?) steps and obtain all the components, built from source, with or without debugging symbols, etc Including:
etc.. Then we can also automate the build and include that from the buildbot.
This should make the code more reliable/maintainable and may well help in solving a number of ugly win32 tickets:
no time - re-scheduling
This is becoming more important so we can ensure that we don't ship vulnerable media libraries (see #544)
Here are some of the mingw packages we will need, available on Fedora 20:
Things we should be able to compile from the mingw shell:
Pythonis likely to be a big problem, see: mingw-and-ndk
Maybe we can mix cross-compilation and native versions? Or maybe we should start considering moving to Python 3 + native clients?, as this may well be easier to build with a cross compiler (see python-mingw)
OK, here are a few things that do build. Loosely based on the list of dependencies found here for OSX builds.
Unless otherwise stated, just run
mingw32-configure && make && make install in the source:
--enable-shared --enable-static --enable-win32thread
unrecognized command line option '-fforce-mem'
wget http://www.ffmpeg.org/releases/ffmpeg-2.2.1.tar.bz2 tar -jxf ffmpeg-2.2.1.tar.bz2 cd ffmpeg-2.2.1 ./configure \ --prefix=/usr/i686-w64-mingw32/sys-root/mingw --arch=x86 --target-os=mingw32 --enable-cross-compile \ --enable-runtime-cpudetect --enable-memalign-hack --enable-gpl \ --disable-everything \ --enable-swscale --enable-libx264 --enable-decoder=h264 \ --enable-libvpx --enable-decoder=vp8 --enable-decoder=vp9 \ --enable-decoder=hevc \ --disable-protocol=tcp --disable-protocol=rtp \ --disable-filter=aformat --disable-filter=crop --disable-filter=setpts \ --disable-filter=anull --disable-filter=format --disable-filter=trim \ --disable-filter=atrim --disable-filter=null \ --disable-programs --disable-avfilter make && make install
Things that do not build (yet?):
patch for cross compiling Python 2.7.6 with mingw
With the patch above (found cross compiling python for windows with mingw32), I can compile Python 2.7.6! (only it didn't find
windres so I edited the
Makefile to point it to
Then we Configure wine to be able to run the new
Python.exe. We can then install
sudo /usr/i686-w64-mingw32/sys-root/mingw/bin/python.exe ./setup.py install
Find out that
Python has been built without SSL support ("
unknown url type: https") and install
mingw32-openssl to rebuild it with
Then we can proceed with the python dependencies using the newly installed
/opt/i686-w64-mingw32/sys-root/mingw/bin/easy_install.exe and add:
lz4. (the others need more work..)
Trying (and failing) to build a simple extension (
--- /opt/i686-w64-mingw32/sys-root/mingw/include/python2.7/pyconfig.h +++ /opt/i686-w64-mingw32/sys-root/mingw/include/python2.7/pyconfig.h @@ -1256,7 +1256,7 @@ /* #undef size_t */ /* Define to `int' if <sys/socket.h> does not define. */ -#define socklen_t int +// #define socklen_t int /* Define to `int' if <sys/types.h> doesn't define. */ #define uid_t int
Then I can try to run the build:
/opt/i686-w64-mingw32/sys-root/mingw/bin/python.exe ./setup.py build --compiler=mingw32
Which fails to find
Python.h... and adding it by hand for now only fails a little bit later... Copying all the headers to the source directory is easier than fighting wine / unix paths, but it eventually still fails.
This is such a pain that maybe #90 is a better way forward?
One problem with this solution is that GTK3 binaries for MS Windows are almost as out of date as the GTK2 version (over 2 years without update..), see GTK Download for Windows:
GTK+ 3.6.4(current release is 3.12)
libpng 1.5.14(see #544 for why this is a very bad thing for us)
So even with this one, we will have to try to rebuild a fair amount of stuff. There are some newer builds here: http://win32builder.gnome.org/, but no idea how well they work and how official they are... what a mess.
I think building pygtk2 from source will just be too hard (cross compiling is a no go because of all the extensions that need to be compiled - already hard enough even without the cross compiling part), especially if we need to update some of the libraries for security reasons (ie:
So I am closing this as
WONTFIX for now, hoping that we can move win32 clients to GTK3 (#90).
Re-opening, GTK3 is going nowhere fast.
@smo: hexchat build?
Should probably be merged / closed as duplicate of #678
Will follow up in #678.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/300