The Mindustry source code makes heavy use of internal Java APIs that
were deprecated in Java 6 and removed in Java 16. It also makes use
of features that require Java >=14.
The author is not ready to provide compatibility with any
maintained Java version at this time.
* add itstool to nativeBuildTools for building help pages in different languages
* add desktop-file-utils and shared-mime-info to nativeBuildTools which are
needed when building
The binutils build system checks by itself if it is building a cross
toolchain or not and prepends or omits a targetPrefix accordingly. This
means that we can always pass target via configureTargets.
However the binutils build system and our bintools wrapper disagree over
whether we are building a cross toolchain or not sometimes since cross
compilation can be relatively subtle in nixpkgs. For example every use
of crossOverlays will make nixpkgs build a cross toolchain even though
localSystem == crossSystem. The cross infrastructure is also used to
build native binaries with a different stdenv (musl instead of glibc,
clang instead of gcc). In all of these cases stdenv.hostPlatform.config
== stdenv.targetPlatform.config, causing binutils to not prepend a
target prefix. At the same time stdenv.hostPlatform !=
stdenv.targetPlatform causing the bintools wrapper to expect a target
prefix, thus building an incomplete set of bintools. This is why
currently pkgsCross.gnu64 and pkgsCross.musl64 aren't working.
The solution is quite simple however: If we detect that we are building
a cross toolchain in the binutils-unwrapped expression, we force the
targetPrefix with --programprefix and fulfill the expectations of the
bintools wrapper at the same time.
Tested (on x86_64-linux):
* pkgsCross.musl64.hello
* pkgsCross.aarch64-multiplatform.hello
* pkgs.hello
Still not working is pkgsCross.gnu64, since
x86_64-unknown-linux-gnu-stage-final-gcc gets confused about targets
now, so bootstrapping the stdenv fails. Since this wasn't working
previously anyways, it's proably fine to fix this separately.
This requires bumping the version of camlimages used by glsurf to a
version that supports current giflib. The most recent versions of
camlimages (even of 4.x) don't support ocaml 4.01 any more, so I've
upgraded to 4.1.2 here, the last version that supports ocaml 4.01 (and
which happily supports current giflib).
libungif was merged into giflib in 2006, and hasn't been updated
since. All non-broken packages still using it build fine with giflib.
See <http://giflib.sourceforge.net/history.html>.
