The cross-builds for Windows are failing now.
The updated binutils version might be incompatible with the toolchain built by MXE Octave.
I guess the underlying issue is that LD_LIBRARY_PATH points to the MXE environment but PATH points to the tools on the build system.
We should probably get that sorted out (either by consistently using tools and libraries from the build system or those that MXE Octave just built).
For the time being, we should probably revert to the older version of binutils.
Let’s see if this will make the buildbots happy again.
There is already a comment in hg-octave-dist.mk that explains why it is difficult to build with our own toolchain.
When I tried to use our toolchain instead, the build failed on creating the images for the manual. We’d need to build (at least) Qt as part of the build toolchain to fix that IIUC.
Not sure if it is related either.
IIUC, libtool will use the ld it found during configure (by calling $CC -print-progname=ld?).
You could check the libtool script that is created by configure which that is. It’s set in line 310 of that script for me:
# The linker used to build libraries.
LD="/usr/bin/ld -m elf_x86_64"
I’m not sure if I correctly follow what LT_PATH_LD is doing. But it might be possible to override whatever it would select by setting lt_cv_path_LD=/usr/bin/ld.lld when configuring…
I’m not sure if I correctly understand the portion of the error message shown in the log of the web interface. Maybe, the version of ICU that is found on the build system is incompatible with the GCC that we are trying to build?
Today, May 2 '22, I get this with a fresh mxe-octave clone:
[philip@localhost mxe_64b_20220205H]$ make nsis-installer
Failed to build package nsis!
Source/exehead/api.h:68:3: warning: 'stdcall' attribute ignored [-Wattributes]
68 | int (NSISCALL *ExecuteCodeSegment)(int, HWND);
Source/exehead/api.h:69:3: warning: 'stdcall' attribute ignored [-Wattributes]
69 | void (NSISCALL *validate_filename)(LPTSTR);
Source/exehead/api.h:70:3: warning: 'stdcall' attribute ignored [-Wattributes]
70 | int (NSISCALL *RegisterPluginCallback)(HMODULE, NSISPLUGINCALLBACK); // returns 0 on success, 1 if already registered and < 0 on errors
In file included from Source/exehead/bgbg.c:24:
Source/exehead/ui.h:25:1: warning: 'stdcall' attribute ignored [-Wattributes]
25 | extern int NSISCALL ui_doinstall(void);
Source/exehead/ui.h:26:1: warning: 'stdcall' attribute ignored [-Wattributes]
26 | void NSISCALL update_status_text(int strtab, const TCHAR *text2);
In file included from Source/exehead/bgbg.c:25:
Source/exehead/util.h:24:10: fatal error: shlobj.h: No such file or directory
24 | #include <shlobj.h>
scons: *** [build/urelease/stub_bzip2-amd64-unicode/bgbg.o] Error 1
scons: building terminated because of errors.
make: *** [/home/philip/devel/octdev/mxe/mxe_64b_20220205H/Makefile:981: build-only-nsis] Error 2
make: Leaving directory '/home/philip/devel/octdev/mxe/mxe_64b_20220205H'
make: *** [Makefile:983: /home/philip/devel/octdev/mxe/mxe_64b_20220205H/installed-packages/nsis] Error 1
Mageia-8 64 bit.
An older mxe-octave build tree (kept up-to-date until last week) still works but yields a bus error at the end while generating the installer .exe. I suspected a zlib update from Mageia but reverting to an older zlib didn’t solve the issue.
Should I enter a bug report for this? Or does anyone ahve suggestions on how to investigate further?
I rearranged the disk layout on my buildbot systems and decided to reinstall the OS from scratch to try to make the two systems more nearly identical. I think the problems are just due to missing packages, but whatever the cause, I’ll try to fix within a few days.
The build-gcc target for the mxe-native-all-on-debian build is failing with
Making all in po
make: Entering directory '/scratch/buildbot/workers/jwe-debian-x86_64-5/mxe-native-all-on-debian/src/tmp-build-gcc/gcc-11.3.0.build/x86_64-pc-linux-gnu/libstdc++-v3/po'
msgfmt -o de.mo /scratch/buildbot/workers/jwe-debian-x86_64-5/mxe-native-all-on-debian/src/tmp-build-gcc/gcc-11.3.0/libstdc++-v3/po/de.po
msgfmt -o fr.mo /scratch/buildbot/workers/jwe-debian-x86_64-5/mxe-native-all-on-debian/src/tmp-build-gcc/gcc-11.3.0/libstdc++-v3/po/fr.po
msgfmt: /scratch/buildbot/workers/jwe-debian-x86_64-5/mxe-native-all-on-debian/src/tmp-build-gcc/gcc-11.3.0.build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /lib/x86_64-linux-gnu/libicuuc.so.71)
make: *** [Makefile:556: de.mo] Error 1
make: *** Waiting for unfinished jobs....
I’m not sure why that is happening. Here’s a full build log: build-gcc.gz (96.8 KB)
Trying to read the log is pretty confusing. Are multiple configure scripts running in parallel? Could that be the cause of the issue? Does invoking make with JOBS=1 lead to a different result?
Other than that: IIUC, msgfmt is a program from the gettext package. At that point (before the GCC compilers are built), the version of msgfmt that is installed on the build system is used. For some reason, it tries to load the just compiled (stage 1) libstdc++.so from GCC’s build tree. It should probably load that library in the version installed on the build system instead. Not sure why it doesn’t.
Are we setting some environment variables that confuse the build process?
The MXE buildbots that target Windows are now failing for some Python packages. I believe we saw that error before. IIRC, it was fixed by installing sudo apt-get install libffi-dev on the build system.
Maybe, the msgfmt that it is using now was built with a newer version of libstdc++ than the one that is built at that point? Or these early stage libraries don’t contain all symbols yet? But then why did it work before?
Anyway, IIUC GCC’s build system never builds its own version of msgfmt. So, it should be safe to always load the libraries installed on the build system for those commands. Does the following patch make any difference? build-gcc-1-msgfmt.diff (870 Bytes)
(Not sure if we’d need to change both files or whether one would be enough…)
Edit: Did you install the same version of the OS as the one that was installed on that worker before? If this is an updated version, maybe the older version packaged libraries that linked against a version of libstdc++.so with a different version suffix. Thus, the libraries might not have clashed like they do now…
# 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
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,
../Include/SLIP_LU.h:154:10: fatal error: mpfr.h: No such file or directory
154 | #include <mpfr.h>
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.
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.
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”…