Buildbot having trouble building MXE Octave

The buildbots that target Windows went a few steps further now. But they failed for ICU4C:
Buildbot: builder w32-on-debian build 1425 (

# build some native tools
mkdir '/scratch/buildbot/workers/jwe-debian-x86_64-5/w32-on-debian/src/tmp-icu4c/icu.native' && cd '/scratch/buildbot/workers/jwe-debian-x86_64-5/w32-on-debian/src/tmp-icu4c/icu.native' && '/scratch/buildbot/workers/jwe-debian-x86_64-5/w32-on-debian/src/tmp-icu4c/icu/source/configure'
checking for ICU version numbers... release 71.1, library 71.1, unicode version 14.0
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking whether to build debug libraries... no
checking whether to build release libraries... yes
checking for clang... clang
checking whether the C compiler works... no
configure: error: in `/scratch/buildbot/workers/jwe-debian-x86_64-5/w32-on-debian/src/tmp-icu4c/icu.native':
configure: error: C compiler cannot create executables
See `config.log' for more details

It looks like configure selects clang as the C compiler. But then proceeds to fail creating executables with it. I pushed the following change to make it use the GCC compilers instead:
mxe-octave: 8b23f76955c6

I hope that’ll fix this error.

It looks like it almost completed the build attempt this time. But p7zip was missing when creating the package.
Buildbot (

generating 7z file...
generating installer script...
/bin/bash: line 1: p7zip: command not found
make: *** [/scratch/buildbot/workers/jwe-debian-x86_64-5/w32-stable-on-debian/src/ 7z-dist] Error 127
make: *** Waiting for unfinished jobs....

Is there anywhere where we document which programs are required to be installed on the build system for MXE Octave?

Not yet, but we seem to be working on it now. :slight_smile:

Once we have it working again, I’ll compile a list and describe as accurately as possible what I’ve done to set up these systems. As always, thanks for your help.


The MXE Windows buildbots seem to be happy now.

The MXE Linux buildbot that uses the system GCC now stops while compiling SuiteSparse with this error:

In file included from ../Source/slip_internal.h:106,
                 from ../Source/SLIP_LU_solve.c:51:
../Include/SLIP_LU.h:154:10: fatal error: mpfr.h: No such file or directory
  154 | #include <mpfr.h>
      |          ^~~~~~~~
compilation terminated.

Currently, we compile GNU MPFR as a dependency of build-gcc. For that configuration (using the system GCC), that dependency isn’t built.
Should we add gcc-mpfr as a dependency to SuiteSparse? I’m not sure if that could cause issues if the version of MPFR in MXE differs from the version that was used for building the system GCC…
Alternatively, we could require that MPFR (and probably also GMP, ISL, and MPC) are installed on the build system if the system GCC should be used.

The latter is probably the safer option.

I pushed the patch from comment #20 to the release branch of the MXE Octave repository in the hope that it will help with the library clash when calling msgfmt:
mxe-octave: 5f64fb928091

Edit: GCC seems to be building now.
However, a similar error is happening when calling out to emacs while building build-gettext:
Buildbot (

Failed to build package build-gettext!
  esac; \
  test -d "$am__dir" || /usr/bin/mkdir -p "$am__dir" || exit 1; \
  emacs --batch \
    $am__subdir_includes -L . -L /scratch/buildbot/workers/jwe-debian-x86_64-5/mxe-native-all-on-debian/src/tmp-build-gettext/gettext-0.21/gettext-tools/emacs \
    --eval '(if (boundp (quote byte-compile-dest-file-function)) (setq byte-compile-dest-file-function (lambda (_) "po-compat.elc")) (defun byte-compile-dest-file (_) "po-compat.elc") )' \
    -f batch-byte-compile '/scratch/buildbot/workers/jwe-debian-x86_64-5/mxe-native-all-on-debian/src/tmp-build-gettext/gettext-0.21/gettext-tools/emacs/po-compat.el'; \
else :; fi
emacs: /scratch/buildbot/workers/jwe-debian-x86_64-5/mxe-native-all-on-debian/src/usr/lib64/ version `GLIBCXX_3.4.30' not found (required by /lib/x86_64-linux-gnu/
emacs: /scratch/buildbot/workers/jwe-debian-x86_64-5/mxe-native-all-on-debian/src/usr/lib64/ version `GLIBCXX_3.4.30' not found (required by /lib/x86_64-linux-gnu/
emacs: /scratch/buildbot/workers/jwe-debian-x86_64-5/mxe-native-all-on-debian/src/usr/lib64/ version `GLIBCXX_3.4.30' not found (required by /lib/x86_64-linux-gnu/

I guess we don’t need the emacs bindings for the gettext that we are using as build tool. Maybe, there are flags to deactivate building those…

Edit 2: Pushed a patch here:
mxe-octave: d18a5545df0d

Looking at my notes for the system reconfiguration, most of the items are specific to my local setup. The important parts for setting up a buildbot worker on a Debian system are:

Install Debian. I chose the testing distribution. At the point when the installation presents a menu of base system components to install, I chose ssh server but no desktop or any other options.

Install other packages

apt build-dep octave
apt install \
  buildbot-worker \
  ccache \
  git \
  libffi-dev \
  libmpfr-dev \
  libxi-dev \
  lzip \
  mercurial \
  p7zip \
  texlive-extra-utils \

Installing the build dependencies for the most recent Octave release will provide most of the necessary tools.

Some of the remaining packages are only needed if the buildbot worker will be building Octave for Windows or a “native” build of Octave and all dependencies. Maybe some of those tools should be built by mxe-octave itself, but requiring them to be installed on the build system works for now. (See also this discussion: Drop “native” builds from mxe-octave?)

Finally, the buildbot worker needs to be configured and started. Then to do anything, the actions for that worker need to be added to the master buildbot configuration.

1 Like

Thanks for summing this up. That will hopefully help in the future. Maybe when we set up the ARM builder? (Is this still planned?)

Is there some place where this can be documented other than in this forum? Maybe somewhere in the Wiki?
I’m afraid this will get lost with time if it is just in a “random comment in some thread on the forum”…