Cannot build violetland using binary mxe distribution (was: build-pkg should install mxe sources)

[ooxi]

When trying to use the binary mxe distribution I stumbled across the error that CMake does not work out of the box, if mxe sources are not located in /usr/lib/mxe. The reason for this is that at least the CMake module files referenced by mxe-cmake.conf are not found.

I think the best way to ensure build-pkg can be used is to install the mxe sources as debian package themself. What do you think @starius ?

[starius]

I can compile my cmake base project using MXE binary distribution.
Could you provide example which fails to build, please?

[ooxi]

The problem only occurs when your require a modified CMake module path for example when trying to build a software requring SDL_image.

For example violetland. If you check out the sources (git submodule init && git submodule update necessary) a simple cmake -DCMAKE_TOOLCHAIN_FILE.. fails since it cannot find SDL_image. The apropriate mxe-... package was installed, of cause :)

[starius]

I have installed sdl-image, sdl-ttf and sdl-mixer from MXE binary distribution, as CMake complained that it could not find them. Now I can compile violetland, but linking fails. CMake in MXE sometimes doesn't link with dependencies of dependencies, see #852. It is unrelated problem. The workaround for now is to add missing libraries manually. Probably this will be solved by MXE's cmake in future.

[ooxi]

I will try again but I could swear sdl-image was installed and not found :/

[tonytheodore]

This is probably more related to #919 in that we don't have a place for common files. The custom cmake modules (mostly SDL* related), fix the lining errors but won't be visible to the toolchain file as they aren't installed by any package.

I'll get #919 sorted before the next packaging run.

[ooxi]

Thanks I will try again manually including the custom cmake modules :)

[ooxi]

I think I slowly go insane, now cmake seems to work but gcc crashes:

Scanning dependencies of target violetland
[  1%] Building CXX object CMakeFiles/violetland.dir/src/program.cpp.obj
In file included from /usr/lib/mxe/usr/x86_64-w64-mingw32.static/include/boost/limits.hpp:19:0,
                 from /usr/lib/mxe/usr/x86_64-w64-mingw32.static/include/boost/format/internals.hpp:21,
                 from /usr/lib/mxe/usr/x86_64-w64-mingw32.static/include/boost/format.hpp:38,
                 from /home/vagrant/violetland/src/program.cpp:33:
/usr/lib/mxe/usr/lib/gcc/x86_64-w64-mingw32.static/5.2.0/include/c++/limits:1598:7: internal compiler error: Illegal instruction
       min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }
       ^
0xad730f crash_signal
    /usr/lib/mxe/tmp-gcc-x86_64-w64-mingw32.static/gcc-5.2.0/gcc/toplev.c:383
Please submit a full bug report,

I have created a Vagrantfile which completely reproduces the issue. @tonytheodore could you tell me which base operating system (jessie vs wheezy, i686-w64-mingw32.static vs x86-64-w64-mingw32.static) and which packages you installed to make compilation and linking work?

[ooxi]

I confirmed the following failure matrix

	wheezy64	jessie64
i686-w64-mingw32.static	CMake cannot find some SDL includes	gcc exception
x86-64-w64-mingw32.static	CMake cannot find some SDL includes	gcc exception

[starius]

I tested violetland build against prebuilt MXE binaries on Jessie amd64 machine in VirtualBox.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.2 (jessie)
Release:        8.2
Codename:       jessie

$ uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) x86_64 GNU/Linux

I copied src from lattest mxe (de5cf69) to /usr/lib/mxe/src but it didn't fix linking errors. I can't reproduce crash when compiling first file.

i686-w64-mingw32.static-gcc is linked against libc. Libc is backward compatible, so binary built in Wheezy should work in Jessie, but bugs happen and changes in libc might result in gcc crash.

[ooxi]

OK the only thing I did different from you was not copying the mxe sources to /usr/lib/mxe/src (this time, I did it before therefore the original issue title). Maybe not having the mxe CMake modules available will cause some strange gcc behaviour.

I'll try to reproduce your findings and come back later :)

[starius]

Yesterday I did it without copying sources. For me the result doesn't depend on presence of sources in /usr/lib/mxe/src.

[ooxi]

Then I don't get why gcc crashes for me on a machine which should be identical to yours (jessie64 in virtual box using mxe precompiled binaries). You do use the binaries from jessie, not wheezy, do you?

[starius]

Jessie.

$ cat /etc/apt/sources.list.d/mxeapt.list
deb http://mxe.redjohn.tk/repos/apt/debian jessie main

Jessie and Wheezy use same Debian packages, except package mxe-requirements which has different sets of packages for Jessie and Wheezy.

[tonytheodore]

@tonytheodore could you tell me which base operating system (jessie vs wheezy...

I wasn't testing the pre-built packages, just that the linking works using the custom cmake modules (OS X 10.10.5).

I'll try the Vagrantfiles and report back.

[tonytheodore]

Then I don't get why gcc crashes for me on a machine which should be identical to yours

It very likely has insufficient RAM for c++ pre-compiled headers, use 2GB to be safe:

config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "2048"]
end

I copied src from lattest mxe (de5cf69) to /usr/lib/mxe/src but it didn't fix linking errors

I moved these to a subdirectory recently so the toolchain file still won't find them:

git clone https://github.com/mxe/mxe.git --depth=1
mkdir /usr/lib/mxe/src
ln -sf /home/vagrant/mxe/src/cmake/modules /usr/lib/mxe/src/cmake

If the custom modules are being used, you should see lines with == Custom MXE File...:

==> default: == Custom MXE File: /usr/lib/mxe/src/cmake/FindSDL_image.cmake
==> default: -- checking for module 'SDL_image'
==> default: --   found SDL_image, version 1.2.12

On Wheezy, you'll also see warnings about Policy CMP0017 is not set, just set this in violetland's CMakeLists.txt.

Run the modified Vagrantfile and you should end up with:

==> default: [ 98%] Building CXX object CMakeFiles/violetland.dir/src/windows/MainMenuWindow.cpp.obj
==> default: [100%] Building CXX object CMakeFiles/violetland.dir/src/windows/CharStatsWindow.cpp.obj
==> default: Linking CXX executable violetland.exe
==> default: [100%] Built target violetland
==> default: violetland.exe: PE32+ executable (console) x86-64, for MS Windows

[starius]

git clone https://github.com/mxe/mxe.git --depth=1
mkdir /usr/lib/mxe/src
ln -sf /home/vagrant/mxe/src/cmake/modules /usr/lib/mxe/src/cmake

This do fix linking errors for me.

[tonytheodore]

This do fix linking errors for me.

Good to hear, the apt packaging itself works flawlessly - well done!

[ooxi]

Thanks for the input, I'll try again and report back!

[ooxi]

I tried again with 2 GiB of memory and once again gcc crashed with the same stack trace :(

[starius]

The error message is similar to known gcc bugs:

1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59463
2. https://stackoverflow.com/questions/30312823/how-to-get-rid-of-internal-compiler-error-illegal-instruction-min-glibcxx-us
3. http://lists.linuxfromscratch.org/pipermail/blfs-support/2015-September/077130.html (+howto debug)

[ooxi]

I think I'll give up on using the prebuild mxe binaries for now. I have created a Vagrant box containing prebuild mxe binaries for everything necessary to compile violetland which should be sufficient for now.

As soon as a new build is available I'll of cause try to use it again :)

Nevertheless providing prebuild mxe binaries is a great job! I'm currently investigating whether it's possible to spare some cycles on some machines at work to build everything in order to help you testing the new toolchain :)