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:
mingw32-winpthreads
, mingw32-xz
, mingw32-xz-libs
mingw32-orc
, mingw32-mpfr
, mingw32-liboil
, mingw32-gmp
mingw32-gtk2
, mingw32-gtkglext
(no pygtkglext
...)
mingw32-gstreamer
, mingw32-gstreamer-plugins-bad-free
, mingw32-gstreamer-plugins-good
mingw32-wavpack
, mingw32-flac
, mingw32-libvorbis
}, mingw32-libwebp
Things we should be able to compile from the mingw shell:
x264
ffmpeg
lame
, libmad
, aac
Potential problems:
Python
is likely to be a big problem, see: mingw-and-ndk
PyOpenGL
, Cython
, numpy
, lz4
, pycrypto
, Pillow
...
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:
ffmpeg
)
--enable-shared --enable-static --enable-win32thread
--fforce-mem
from the CFLAGS
in the Makefile
to avoid: unrecognized command line option '-fforce-mem'
--without-mp4v2
--disable-dccp --disable-librfb
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 /usr/bin/i686-w64-mingw32-windres
)
Then we Configure wine to be able to run the new Python.exe
. We can then install setuptools
:
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 https
support...
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: pyasn1
, lz4
. (the others need more work..)
Trying (and failing) to build a simple extension (netifaces
):
--- /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
CC=/usr/bin/i686-w64-mingw32-gcc
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: libpng
.
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
There are 3 tickets that should be consolidated into one: #917, #678 and #300
Milestone renamed
Will follow up in #678.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/300