Skip to content

Windows 64 bit compilation using mingw64

Albert Gräf requested to merge aggraef/purr-data:mingw64-base into master

Note: To test this, the same dependencies as for the mingw32 build need to be installed for mingw64. I have already tested this MR extensively, in fact it's the version I've been running for a while now, on Linux, Mac and Windows.

I'm keeping this as WIP for now, since I most likely have to fix some rebase conflicts after !529 (merged), !531 (merged), !530 (merged), and !528 (merged) have gone in.

This touches on many parts of the sources in order to make it possible to compile Purr Data as a 64 bit Windows package, so I explain what the various commits do below.

The Essential Parts

  • Rev. d747933b fixes a spurious segfault that I've been seeing only in the Windows 64 bit version when running regression_tests.pd. The segfault happens in glob_quit(), and can be avoided by skipping the (unneeded) GUI cleanup when running gui-less (sys_nogui).

  • Rev. 6b376222 enables 64 bit compilation in the tar_em_up.sh script and fixes some basic problems which make mingw64 compilation fail.

  • Rev. 94c62e36 is at the heart of this MR and fixes all the little things that prevent Purr Data to properly compile in mingw64, so that it will also run correctly afterwards. These are mostly wrong type casts and format conversions (printf, scanf, post, et al). The format conversions need some special diligence, because long ints are always 4 bytes in Windows (even 64 bit Windows), whereas pointers are 4 bytes in mingw32 and 8 bytes in mingw64. The only reasonable way to deal with pointer-sized integer values in a cross-platform way is to use the %z specifier which always has the right size for a pointer-sized int value; %llx is the wrong size in mingw32, whereas %lx is the wrong size in mingw64. Unfortunately, the MSVC printf/scanf routines are not ANSI-compatible and do not support %z. But mingw provides ANSI C-compatible printf/scanf routines which need to be enabled by setting __USE_MINGW_ANSI_STDIO = 1.

  • Rev. 9e0da7d7, 6198bf62, and dfdb7c47 fix various mingw64 compilation issues in externals (moocow, lyonpotpourri) and the included portmidi sources.

  • Rev. d5bf614d sets up tar_em_up.sh for mingw64 compilation, and rev. aecae73c adds the required win64_inno package.

The Not So Essential Parts

These parts can be omitted, but are highly recommended.

  • Rev. a00d66e5 adds some machinery to prevent stripping of the binaries when debugging options are present, so that the resulting binaries will actually work with gdb.

  • Rev. 9670411d adds a t_uint type to m_pd.h which is t_int's unsigned counterpart. Using this type instead of t_int doesn't change the resulting code, but it silences all those annoying signed-ness warnings that would otherwise appear with the %z specifier, and considerably reduces noise in the build logs.

  • Rev. 0ff95234 silences some additional format-related warnings in the mrpeach externals.

  • Rev. 2f3c815a changes external-tests.pd so that it will be content with 2176 objects for a successful test. This can be left out, but then the externals test will fail even though the resulting Purr Data build is seemingly working fine. I'm not sure why the 64 bit build has less objects in Windows, because the set of produced external dlls is exactly the same, and they are all proper PE32+ x64 dlls which seem to load fine. Maybe there's some content in externals that gets excluded in a mingw64 bit compilation?

  • Rev. ff179e72 makes tar_em_up.sh use our default nw.js version 0.24.4 also for the mingw32 build. If I'm not mistaken, we're still using 0.14.7 right now since that was the last version to support Windows XP. But nw.js 0.14.7 is bug-ridden and slow on modern 64 bit Windows systems, and is some serious technical debt at this point, so we really shouldn't use it any more. Let Windows XP rest in peace. People still running Windows XP now surely have a lot of more serious problems to worry about than being able to run Purr Data.

The Optional Parts

These parts are entirely optional, but still nice to have.

  • Rev. e1d3dfb6 replaces the weird-looking NextButtonClick prefix to some Inno Setup messages with something more sensible, in both the win32_inno and win64_inno packages. To me, that NextButtonClick prefix looks just ugly, like something that a developer forgot to change after copy-pasting some Inno Setup code from the web.
Edited by Albert Gräf

Merge request reports