Where is the mingw cross-compiler?

Help
1

I have been using the Mingw32 cross compiler in Linux for creating Windows executables for many years, but lately it doesn’t seem to be in any of the usual RPM style repositories.

yum search mingw

doesn’t turn anything up, nor does dnf. There is a page:

https://fedoraproject.org/wiki/MinGW

that seems to offer the software, but no link and no name is given. I don’t need the most recent version - something from 2008 would be fine. 32 or 64 bit is fine. gcc or LLVM are fine. Any compiler that will run in Centos and produce Windows exe files from standard f77 is fine. I would like to avoid a virtual machine or container, though.

I did find a version for FreeBSD in the the ports collection, and I was able to build that from source, and it does work. But I am still looking for a Linux version as the rest of the project is mostly Linux based.

Daniel Feenberg
NBER

1 Like
2

I have no experience with MinGW, nor Fedora. On the other hand – since mingw doesn’t show up in Debian’s package manager synaptic either – typing just mingw in Debian’s package tracker points to multiple entries, including binutils-mingw-w64 with a time stamp of 2021-11-02 for Debian’s branch testing (12/bookworm) (more details here eventually lead to download a .deb package).

Like there is benefit to complement Windows by a WSL or a .true. Linux installation, the cohabitation of two (or more) different Linuxes on one machine requires some rules but then equally works fine. Possibly equally here.

3

You can try to search in https://repology.org/ for the MinGW cross toolchain, Fedora is for sure included in the repology database. Note that the naming of the cross-compiler is probably very inconsistent across distributions.

4

The string “mingw” is used in the names of two separate projects. One is Windows compiler forked from gcc, another is a cross compiler for Linux or Freebsd that compiles to Windows executables, also forked from gcc. As far as I can tell, everything in Repology is either the Windows compiler, or it’s libraries, none are for the cross-compiler. I can’t be sure of that, since none of the packages listed have any sort of descriptive label. “binutils” is identified on the gcc site as a collection of routines other than the compiler itself. There are a couple of links to packages call “mingw-gcc-*” which would be where the compiler should be, but they are very small - a few hundred lines, so they can’t be a cross-compiler.

It is a pity that a significant development effort for something so potentially valuable seems so hard to find. It is out there somewhere.

5

For Arch Linux there is Arch Linux - mingw-w64-gcc 12.1.0-1 (x86_64), which is the actual cross-compiler.

Searching repology for mingw in the Fedora repositories returns its C runtime: Overview - rpms/mingw-crt - src.fedoraproject.org. By analogy one could guess that there is probably a compiler as well: Overview - rpms/mingw-gcc - src.fedoraproject.org.

Since it doesn’t show up in the repo, it might have been dropped from the Fedora distribution. You can always reach out to the Fedora project and volunteer as new maintainer for the MinGW cross-compiler, checkout Fedora Packaging Guidelines :: Fedora Docs for more details on how to get involved with the Fedora project (I haven’t packaged for Fedora yet, but I know at least one Fedora package maintainer).

6

What worked for me on Ubuntu 20.04 (Focal) was:

$ sudo apt-get install mingw-w64
$ sudo apt-get install gfortran-mingw-w64-x86-64
$ sudo apt-get install wine  # to run the programs

This required roughly 2 GB of memory.

Next I created the following CMake toolchain file:

# mingw.cmake

# the name of the target operating system
set(CMAKE_SYSTEM_NAME Windows)

# which compilers to use for C and C++
set(CMAKE_C_COMPILER   x86_64-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
set(CMAKE_Fortran_COMPILER x86_64-w64-mingw32-gfortran)

# where is the target environment located
set(CMAKE_FIND_ROOT_PATH  /usr/x86_64-w64-mingw32)

# adjust the default behavior of the FIND_XXX() commands:
# search programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

# search headers and libraries in the target environment
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

The toolchain file can be referenced in the build configuration step:

~fortran/win/build$ cmake -DCMAKE_TOOLCHAIN_FILE=../mingw.cmake ..

Otherwise you just use CMake as usual:

cmake_minimum_required(VERSION 3.15.0 FATAL_ERROR)

project(test VERSION 0.1.0 LANGUAGES CXX C Fortran)

if(CMAKE_SYSTEM MATCHES Windows)
   message(STATUS "Target system is Windows")
endif()

add_executable(main main.cpp)

add_executable(main-f90 main.f90)
if(CMAKE_CROSSCOMPILING)
    target_link_libraries(main-f90 PUBLIC "-static")
endif()

The main Fortran program was:

program main
use iso_fortran_env
print '(4a)', 'This file was compiled by ', &
              compiler_version(), ' using the options ', &
              compiler_options()
end program

Here is the output:

:~/fortran/win/build$ make main-f90
Scanning dependencies of target main-f90
[ 50%] Building Fortran object CMakeFiles/main-f90.dir/main.f90.o
[100%] Linking Fortran executable main-f90.exe
[100%] Built target main-f90
~/fortran/win/build$ wine ./main-f90.exe
This file was compiled by GCC version 9.3-win32 20200320 using the options -mtune=generic -march=x86-64 -auxbase-strip CMakeFiles/main-f90.dir/main.f90.o

I was quite surprised by how easy cross-compiling was. It’s a great showcase of the work that goes into MinGW, GCC, and CMake.

I wonder if it’s possible to develop QuickWin (Intel) or AppGraphics (Approximatrix, cc @jeff) apps this way?

1 Like
7

It should work fine if one wanted to use the AppGraphics library. It looks like the gfortran-mingw-w64-x86-64 package does pull in the mingw-w64-x86-64-dev package, which contains all the Win32 development libraries for linking.

The only catch might be that we only distribute a .mod interface rather than the source for the module, so the compiler would have to be compatible. However, I don’t think GNU Fortran has changed .mod files since maybe GNU Fortran 9 or so (used to be a perpetual issue)…