Skip to main content

How to contribute to the xPack MinGW-w64 GCC

license

This page is designed for developers who plan to contribute new features or fix bugs in the xPack MinGW-w64 GCC project and provides documentation on how to build and test the package.

The xPack Build Box

The build scripts in this project use the xPack Build Box (XBB) tools, which require the usual native development tools (packed as a Docker image for GNU/Linux builds), complemented with several binary packages, installed with xpm as development dependencies.

For those interested in understanding how things work, a good starting point would be to read the XBB page.

caution

The XBB tools are intended for building standalone relocatable distributions, thus are quite complex and perform several post-processing steps to adjust RPATH and validate the resulting binaries.

For the traditional configure && make install builds specific to Linux, these scripts are probably too complicated and therefore are not recommended for inexperienced users.

xPack build configurations

The xPack Framework supports projects with multiple build configurations.

Build configurations are sets of properties, actions and dependencies that apply to a specific build. Build configurations can inherit from other build configurations.

For simple projects, the typical use case is with two configurations, Debug and Release.

For building the binary xPack executables, there is one configuration for each platform:

  • win32-x64
  • darwin-x64
  • darwin-arm64
  • linux-x64
  • linux-arm64
  • linux-arm
note

In case you wonder where these names come from, they are exactly the Node.js process.platform and process.arch for each platform.

The build configurations are defined in the package.json file, in the xpack section.

{
  "...":"...",
  "xpack": {
    "buildConfigurations": {
      "...": {
      },
      "win32-x64": {
        "inherit": [
          "common-dependencies",
          "common-actions",
          "common-docker"
        ],
        "devDependencies": {
          "@xpack-dev-tools/gcc": "13.2.0-2.1",
          "@xpack-dev-tools/mingw-w64-gcc": "13.2.0-1.1",
          "@xpack-dev-tools/wine": "8.0.2-1.1"
        },
        "properties": {
          "dockerImage": "ilegeul/ubuntu:amd64-18.04-xbb-v5.2.2"
        },
        "actions": {
          "build": "{{properties.commandBashBuild}} --windows",
          "build-development": "{{properties.commandBashBuild}} --windows --development",
          "build-development-debug": "{{properties.commandBashBuild}} --windows --development --debug",
          "build-development-tests-only": "{{properties.commandBashBuild}} --windows --development --tests-only"
        }
      }
    }
  }
}

To ask xpm to perform a specific action on a given build configuration, use the --config <name> option.

For example:

xpm install --config darwin-x64
xpm run build --config darwin-x64
xpm/xPack actions

The xpm actions are extensions of npm scripts, i.e. named sequences of commands that are invoked via xpm run <name> to perform specific operations. together in a sub-shell .

The commands are invoked in a sub-shell with an adjusted PATH, having the xpacks/.bin folder prepended. This ensures the locally installed tools are preferred to the system tools.

Actions can be defined for the entire project or for a specific build configuration.

The actions are defined in the package.json file, in the xpack section, at the top or inside build configurations.

tip

For those who, for various reasons, can not use xpm, it is perfectly possible to manually adjust the PATH and to invoke the sequence of commands in order, just that it is more tedious, since multiple substitutions must be performed to compose the commands.

Visual Studio Code integration

xpm/xPack actions and build configurations are supported in Visual Studio via the xPack C/C++ Managed Build Tools extension.

With this extension installed, xpm/xPack actions can be very conveniently invoked via a single mouse click, for example:

xPack actions

Prerequisites​

The build scripts run on GNU/Linux and macOS. The Windows binaries are compiled on x64 GNU/Linux, using mingw-w64.

For details on installing the prerequisites, please read the Build Prerequisites page.

Get project sources​

The project is hosted on GitHub:

Branches

Apart from the unused master branch, there are three active branches:

  • xpack, with the latest stable version (default)
  • xpack-development, with the current development version
  • website, with the current content of the website

All development is done in the xpack-development branch, and contributions via Pull Requests should be directed to this branch.

When new releases are published, the xpack-development branch is merged into xpack.

Pushes to the website branch trigger a GitHub Action to generate and publish the project web site.

To clone the stable branch (xpack), run the following commands in a terminal (on Windows use the Git Bash console):

rm -rf ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
git clone https://github.com/xpack-dev-tools/mingw-w64-gcc-xpack.git \
  ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
For development purposes, clone the xpack-development branch.
rm -rf ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git && \
mkdir -p ~/Work/xpack-dev-tools && \
git clone \
  --branch xpack-development \
  https://github.com/xpack-dev-tools/mingw-w64-gcc-xpack.git \
  ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git
tip

To contribute Pull Requests, fork the project and be sure the Copy the master branch only is disabled.

Use the xpack-development branch and be sure you contribute the Pull Requests back to the xpack-development branch.

::

Get the writable helper sources (optional, for development purposes)

The project has a dependency to a common helper, that is normally installed as a read-only dependency; for development purposes, to be able to make changes to the scripts located inside the helper, clone the xpack-development branch and link it to the user global xPacks store:

rm -rf ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
mkdir -p ~/Work/xpack-dev-tools && \
git clone \
  --branch xpack-development \
  https://github.com/xpack-dev-tools/xbb-helper-xpack.git \
  ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git

For more details the how a writable helper can be used via xpm link, please see the XBB documentation.

Other repositories​

Other repositories in use are:

  • none

How to build​

The builds require dedicated machines for each platform (x64 GNU/Linux, armh64 GNU/Linux, arm GNU/Linux, x64 macOS and arm64 macOS).

Update the repo​

git -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git pull
... and the helper (when using a writable helper) ...
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull

Build the binaries​

The Windows builds run on GNU/Linux, using mingw-w64.

To prepare the docker build:

xpm run install -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build-assets && \
xpm run docker-prepare --config win32-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build-assets
... or, with the writable helper ...
xpm run install -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build-assets && \
xpm run link-deps -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build-assets && \
xpm run docker-prepare --config win32-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build-assets && \
xpm run docker-link-deps --config win32-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build-assets

To run the docker build:

xpm run docker-build --config win32-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build-assets

or, for more verbosity, run the similar development build:

xpm run docker-build-development --config win32-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build-assets

About 137 minutes (2h17m) later, the output of the build script is a compressed archive and its SHA signature, created in the build-assets/build/win32-x64/deploy folder:

  • xpack-mingw-w64-gcc-14.2.0-1-win32-x64.tar.gz
  • xpack-mingw-w64-gcc-14.2.0-1-win32-x64.tar.gz.sha

To rerun the build, invoke the deep-clean action and repeat from install:

xpm run deep-clean --config win32-x64 -C ~/Work/xpack-dev-tools/mingw-w64-gcc-xpack.git/build-assets

Compile with debug info​

In some cases it is necessary to run a debug session with the binaries.

For these cases, the build script accepts the --debug options.

There are also xpm actions that use this option (build-development-debug and docker-build-development-debug).

Use a local cache​

The XBB build scripts use a local cache such that files are downloaded only during the first run, later runs being able to use the cached files.

However, occasionally some servers may not be available, and the builds may fail.

The workaround is to manually download the files from alternate locations (like https://github.com/xpack-dev-tools/files-cache/tree/master/libs), place them in the XBB cache (Work/cache) and restart the build.

Notes​

Output folder hierarchy​

The scripts build separate 32/64-bit versions of all tools, installed in separate folders ("x86_64-w64-mingw32" "i686-w64-mingw32"); the binaries are installed in bin and are prefixed.

The target specific dependencies are also installed in separate folders below a folder specific to the build machine (like x86_64-apple-darwin21.6.0).

├── README.md
├── bin
│   ├── i686-w64-mingw32-addr2line
│   ├── i686-w64-mingw32-ar
│   ├── i686-w64-mingw32-as
│   ├── i686-w64-mingw32-c++
│   ├── i686-w64-mingw32-c++filt
│   ├── i686-w64-mingw32-cpp
│   ├── i686-w64-mingw32-dlltool
│   ├── i686-w64-mingw32-dllwrap
│   ├── i686-w64-mingw32-elfedit
│   ├── i686-w64-mingw32-g++
│   ├── i686-w64-mingw32-gcc
│   ├── i686-w64-mingw32-gcc-12.2.0
│   ├── i686-w64-mingw32-gcc-ar
│   ├── i686-w64-mingw32-gcc-nm
│   ├── i686-w64-mingw32-gcc-ranlib
│   ├── i686-w64-mingw32-gcov
│   ├── i686-w64-mingw32-gcov-dump
│   ├── i686-w64-mingw32-gcov-tool
│   ├── i686-w64-mingw32-gendef
│   ├── i686-w64-mingw32-gfortran
│   ├── i686-w64-mingw32-gprof
│   ├── i686-w64-mingw32-ld
│   ├── i686-w64-mingw32-ld.bfd
│   ├── i686-w64-mingw32-lto-dump
│   ├── i686-w64-mingw32-nm
│   ├── i686-w64-mingw32-objcopy
│   ├── i686-w64-mingw32-objdump
│   ├── i686-w64-mingw32-ranlib
│   ├── i686-w64-mingw32-readelf
│   ├── i686-w64-mingw32-size
│   ├── i686-w64-mingw32-strings
│   ├── i686-w64-mingw32-strip
│   ├── i686-w64-mingw32-widl
│   ├── i686-w64-mingw32-windmc
│   ├── i686-w64-mingw32-windres
│   ├── x86_64-w64-mingw32-addr2line
│   ├── x86_64-w64-mingw32-ar
│   ├── x86_64-w64-mingw32-as
│   ├── x86_64-w64-mingw32-c++
│   ├── x86_64-w64-mingw32-c++filt
│   ├── x86_64-w64-mingw32-cpp
│   ├── x86_64-w64-mingw32-dlltool
│   ├── x86_64-w64-mingw32-dllwrap
│   ├── x86_64-w64-mingw32-elfedit
│   ├── x86_64-w64-mingw32-g++
│   ├── x86_64-w64-mingw32-gcc
│   ├── x86_64-w64-mingw32-gcc-12.2.0
│   ├── x86_64-w64-mingw32-gcc-ar
│   ├── x86_64-w64-mingw32-gcc-nm
│   ├── x86_64-w64-mingw32-gcc-ranlib
│   ├── x86_64-w64-mingw32-gcov
│   ├── x86_64-w64-mingw32-gcov-dump
│   ├── x86_64-w64-mingw32-gcov-tool
│   ├── x86_64-w64-mingw32-gendef
│   ├── x86_64-w64-mingw32-gfortran
│   ├── x86_64-w64-mingw32-gprof
│   ├── x86_64-w64-mingw32-ld
│   ├── x86_64-w64-mingw32-ld.bfd
│   ├── x86_64-w64-mingw32-lto-dump
│   ├── x86_64-w64-mingw32-nm
│   ├── x86_64-w64-mingw32-objcopy
│   ├── x86_64-w64-mingw32-objdump
│   ├── x86_64-w64-mingw32-ranlib
│   ├── x86_64-w64-mingw32-readelf
│   ├── x86_64-w64-mingw32-size
│   ├── x86_64-w64-mingw32-strings
│   ├── x86_64-w64-mingw32-strip
│   ├── x86_64-w64-mingw32-widl
│   ├── x86_64-w64-mingw32-windmc
│   └── x86_64-w64-mingw32-windres
├── distro-info
│   ├── CHANGELOG.md
│   ├── licenses
│   ├── patches
│   └── scripts
├── i686-w64-mingw32
│   ├── bin
│   ├── include
│   └── lib
├── include
│   ├── ctf-api.h
│   ├── ctf.h
│   └── libiberty
├── lib
│   ├── bfd-plugins
│   ├── gcc
│   ├── libcc1.0.so
│   ├── libcc1.a
│   ├── libcc1.la
│   ├── libcc1.so -> libcc1.0.so
│   ├── libctf-nobfd.0.dylib
│   ├── libctf-nobfd.a
│   ├── libctf-nobfd.dylib -> libctf-nobfd.0.dylib
│   ├── libctf-nobfd.la
│   ├── libctf.0.dylib
│   ├── libctf.a
│   ├── libctf.dylib -> libctf.0.dylib
│   ├── libctf.la
│   └── libiberty.a
├── libexec
│   ├── libgmp.10.dylib
│   ├── libiconv.2.dylib
│   ├── libisl.23.dylib
│   ├── libmpc.3.dylib
│   ├── libmpfr.6.dylib
│   ├── libz.1.2.11.dylib
│   ├── libz.1.dylib -> libz.1.2.11.dylib
│   └── libzstd.1.5.2.dylib
├── share
│   └── gcc-12.2.0
├── x86_64-apple-darwin21.6.0
│   ├── i686-w64-mingw32
│   └── x86_64-w64-mingw32
└── x86_64-w64-mingw32
    ├── bin
    ├── include
    └── lib

24 directories, 95 files

Bootstrap​

Compiling the Windows binaries require a bootstrap, which is more or less the same thing, but configured to run on Linux, not on Windows (the binaries are ELFs, not EXEs).

The bootstrap is built in a separate folder (x86_64-pc-linux-gnu), and includes only a single target specific folder (x86_64-w64-mingw32) since only 64-bit Windows binaries are finally created.

Note: The bootstrap cannot be replaced by an external mingw-gcc package since it is mandatory to be of exactly the same version as the final release, otherwise subtle header differences might break the build (in theory it might be possible to configure the build to use an older compiler and the current headers, but in practice this proved tricky).

DLLs​

The compiled binaries refer to various DLLs.

% ls -l x86_64-w64-mingw32/lib/*.dll
-rwxr-xr-x  1 ilg  staff    38296 Dec  1 21:14 x86_64-w64-mingw32/lib/libatomic-1.dll
-rwxr-xr-x  1 ilg  staff   662864 Dec  1 21:14 x86_64-w64-mingw32/lib/libgcc_s_seh-1.dll
-rwxr-xr-x  1 ilg  staff  3132646 Dec  1 21:14 x86_64-w64-mingw32/lib/libgfortran-5.dll
-rwxr-xr-x  1 ilg  staff   261049 Dec  1 21:14 x86_64-w64-mingw32/lib/libgomp-1.dll
-rwxr-xr-x  1 ilg  staff   378712 Dec  1 21:14 x86_64-w64-mingw32/lib/libquadmath-0.dll
-rwxr-xr-x  1 ilg  staff    23251 Dec  1 21:14 x86_64-w64-mingw32/lib/libssp-0.dll
-rwxr-xr-x  1 ilg  staff  1990289 Dec  1 21:14 x86_64-w64-mingw32/lib/libstdc++-6.dll
-rwxr-xr-x  1 ilg  staff    61808 Dec  1 21:10 x86_64-w64-mingw32/lib/libwinpthread-1.dll

When running the binaries, this folder must be added to the Windows path.

libwinpthread-1.dll​

Due to the specifics of the MinGW-w64 build, the threading library is not very well integrated into the build, and invoking the compiler with -static-libgcc -static-libstdc++ does not apply to this DLL, so the resulting binaries might still have a reference to it.