Unfortunately, newer versions of linux-pam throw compilation problems:
linux-pam 1.5.3:
tty_conv.c:9:10: fatal error: termio.h: No such file or directory
linux-pam 1.6.0:
pam_namespace.c:649:41: error: 'SIZE_MAX' undeclared (first use in this function)
With setup-beam v1.17.2, make-binaries failed in the Container action with:
* ERROR: No usable Erlang/OTP system for the build machine found! Cannot
* cross compile without such a system.
*
* Either build a bootstrap system for the build machine, or provide
* an Erlang/OTP-26 system in the $PATH, and try again. For more
* information on cross compiling Erlang/OTP-26, see the
* $ERL_TOP/xcomp/README file.
The problematic commit is:
cf854bf149
more concretely this change:
- core.exportVariable(installDirForVarName, cachePath)
+ core.exportVariable(installDirForVarName, catchPathBin)
Up until setup-beam@v1.17.1, the INSTALL_DIR_FOR_OTP was something like
/opt/hostedtoolcache/otp/ubuntu-22.04/OTP-26.1.1/x64
but starting in v1.17.2, the path contains /bin, for example:
/opt/hostedtoolcache/otp/ubuntu-22.04/OTP-26.1.1/x64/bin
Omit the directory that contains cross compilation tools without
"$target-" prefix from the PATH. Having it in the path might lead to
problems when native tools are needed during cross compilation. For
actual cross compilation, the prefixed tools should always be used
anyway.
control+g is the correct way to enter shell break mode, as documented in
https://www.erlang.org/doc/apps/erts/tty
The ejabberdctl script included in installers use the included VT100,
and that may break when hitting control+c.
In that scenario let's explicitly recommend to not use control+c.
Thanks to Holger Weiß for the report.
This updates the mix.exs code from commit 8ca12d4 (ejabberd 21.07)
Consequently, no need in make-binaries to update ERLANG_NODE.
The ecs docker image 23.04 got a similar change in
f81905d5e3
The default is to link against the most-recent musl version available
within the crosstool-ng toolchain, which is currently 1.2.2. Unlike
with glibc, there's no point in sticking to some older version.
The CT_GLIBC_KERNEL_VERSION_NONE option is about the minimum kernel
version supported by the toolchain's glibc. The default is to stick to
the version of the kernel headers, which should be just fine.
make-*: include musl build in make-binaries
Ctr actions: use github runners to provide bootstrap erlang
- adjust make-binaries script to use github runners' installed erlang
for bootstrapping
- this reduces the need to build an unnecessary toolchain for glibc
based binaries
Update zlib to 1.2.13 to address CVE-2022-37434
Also change zlib download to use archive URL so builds do not fail
when specified version is no longer the current version
Don't break the (currently nonexistent) case where a dependency's
rebar.config file specifies LDFLAGS before and after "-lstdc++", such as
"-lfoo -lstdc++ -lbar".
