Cross compile app for Win32, from 32 bit Linux, using i586-mingw32msvc-g++

[ElColmo]

Hi,

I'm trying to cross-compile an SFML 2.0 app for Win32, from my Linux box, using the following MinGW compiler:

# i586-mingw32msvc-g++ -v
Using built-in specs.
Target: i586-mingw32msvc
Configured with: /build/buildd/mingw32-4.2.1dfsg/build_dir/src/gcc-4.2.1-2-dfsg/configure  -v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++ --enable-threads --enable-sjlj-exceptions --disable-multilib --enable-version-specific-runtime-libs
Thread model: win32
gcc version 4.2.1-sjlj (mingw32-2)
#

The background is the following:
I can build SFML and a test app on 32 bit Linux natively (but not on 64 bit), and it runs fine. 
When I try to cross-compile SFML 2.0 for Windows, I get errors.

Here's what I'm doing.. all manual, so there should be no "tool-config" type errors creeping in anywhere.

# sudo apt-get install cmake mingw32
# wget http://www.sfml-dev.org/download/sfml/2.0/SFML-2.0-sources.zip
# unzip SFML-2.0-sources.zip
# cd SFML-2.0
# rm -rf CMakeFiles Makefile
# cmake -DCMAKE_TOOLCHAIN_FILE=../MinGW_toolchain.cmake -G "Unix Makesfiles" -D  CMAKE_BUILD_TYPE=Release -D BUILD_SHARED_LIBS=TRUE .
# make

I get the following error:
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
 Could NOT find Freetype (missingL FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS)
..

I guess my questions are the following:
1: Is there an easier way of doing this?  I tried using the SFML binaries for Windows, but could not cross-compile successfully against them
2: Does anyone happen to have Windows SFML binaries suitable for use with this version of MinGW/G++?
3: If the answer to 1 and 2 is "No", then do I need to install the Windows dev source for all the dependent libraries that SFML uses?

Thanks, any help appreciated..
ElColmo

[Anonymouseable]

The headers are the same between different platforms so no you won't need to download different dev packages.
However you will need to get compatible binary versions of the libraries SFML depends on (freetype, glew, sndfile, openal). The versions included in the extlibs directory should be compatible (I think), but CMake might simply not want to use them because of some variables that are usually defined when compiling for windows but aren't by your toolchain file. Could you upload the toolchain file?

[ElColmo]

Thanks.  I hadn't seen the libs in the SFML source distro. 

That got me a few steps further.  I was also missing the LIBRARY and INCLUDE variables for the various libraries in the toolchain file.  Now it's failing like so:

Linking CXX shared library ../../../lib/sfml-graphics-2.dll
..
undefined reference to `glewInit'
undefined reference to `_jpeg_std_error'
etc.

I would have thought that there was a script to perform this process already, since the MinGW binary downloads on the website must be produced using a method such as this, using MinGW, on Linux, to create Windows binaries.

Rgds,
ElColmo

[eXpl0it3r]

I always suggest to build native. Not only doesn't cross-compiling work all the time, but it's often also more time intensive than quickly installing VirtualBox with Windows and compiling it there.

As for the errors, it means that you have to link against the dependencies like GLEW, JPEG, etc.
Also keep in mind that SFML's CMake script might fail for cross-compilation.

[Anonymouseable]

Thanks.  I hadn't seen the libs in the SFML source distro. 

That got me a few steps further.  I was also missing the LIBRARY and INCLUDE variables for the various libraries in the toolchain file.  Now it's failing like so:

Linking CXX shared library ../../../lib/sfml-graphics-2.dll
..
undefined reference to `glewInit'
undefined reference to `_jpeg_std_error'
etc.

I would have thought that there was a script to perform this process already, since the MinGW binary downloads on the website must be produced using a method such as this, using MinGW, on Linux, to create Windows binaries.

Rgds,
ElColmo

No, the builds on the site are probably made using MinGW on Windows. As for finding the libraries, it's possible that your toolchain script doesn't define all the necessary CMake variables. As I said:

Could you upload the toolchain file?