add arm7le machine type, configure supoprt for Termux, arm32 FFI repairs

[mflatt]

The arm7le machine type corresponds to ARMv7 armel (like Android), while arm32le is still ARMv6 armhf (like Raspberry Pi).

I was not able to set up a 32-bit ARM Termux environment to make sure everything works. I tired out Arm64 Termux, and I built on armel Debian to test tarm7le.

Running "foreign.ms" tests on arm32le, meanwhile, exposed old problems via tests that were added relatively recently. Those problems involved unusual situations: __collect-safe mode, structs with unions that have only floating-point fields, and callables that have struct results and floating-point arguments.

Closes #1049, #1040, #1041

[cosmos72]

That was fast!
I've successfully compiled and installed ChezScheme with this patch on a 32-bit arm Android tablet, and it works basically perfectly, including all floating point computations and (foreign-procedure) that I tried. mpressive.

[cosmos72]

A minor note: checking for environment variable $TERMUX_VERSION is not very robust - the termux app from Google Play Store defines it, while the one from F-Droid does not.

A more thorough solution for detecting termux is [ "$(uname)" = "Linux" -a "$(uname -o)" = "Android" ]

For completeness: uname -o is Linux-specific, and it curiously prints Linux on pure Android - as for example from adb shell - while it prints Android from Termux app running on Android.

So the Linux-specific configure fragment

    if [ -n "$TERMUX_VERSION" ]; then
        hardlinks=no
    fi

could be rewritten as

   if [ "$(uname -o)" = "Android" ]; then
        hardlinks=no
   fi

Similary, the configure fragment

        if [ -n "$TERMUX_VERSION" ]; then
            m32=arm7${unixsuffix}
            tm32=tarm7${unixsuffix}
        fi

could be rewritten as follows, taking advantage of $CONFIG_UNAME already being set to $(uname)

        if [ "$CONFIG_UNAME" = "Linux" -a "$(uname -o)" = "Android"  ]; then
            m32=arm7${unixsuffix}
            tm32=tarm7${unixsuffix}
        fi

And the final configure fragment

        if [ -n "$TERMUX_VERSION" ]; then
            LDFLAGS="${LDFLAGS} ${iconvLib}"
        fi

could be rewritten as

        if [ "$CONFIG_UNAME" = "Linux" -a "$(uname -o)" = "Android"  ]; then
            LDFLAGS="${LDFLAGS} ${iconvLib}"
        fi

[mflatt]

@cosmos72 Thanks for the pointers! I've opted to set an android variable in the initial CONFIG_UNAME switch. I think it still does the right thing for 64-bit Arm installed via a GitHub release of Termux, at least. A further check by you to make it it works more generally would be helpful.

[cosmos72]

Where can I find the new (or updated) PR ?

[mflatt]

Oops - now pushed here!

[cosmos72]

Apart from the trivial default initialization android=yes that should be android=no, looks good to me.

The missing include <errno.h> reported by CI is worth fixing, but looks unrelated to this pull request.

Tested on:
Termux version googleplay.2026.06.21 (from google play) on Android 11 tarm7le

Termux version 0.118.3 (from f-droid) on Android 16 tarm64le

[mflatt]

The missing include <errno.h> reported by CI is worth fixing, but looks unrelated to this pull request.

I think that was due to the android=yes mistake. Let's see how the fixed version goes.

[mflatt]

It wasn't obvious to me how the android=yes mistake led to the compilation error with errno, so I investigated a little more. The reason is that adding -liconv breaks zlib's configure script's conclusions when libiconv does not exist in the compilation environment, causing it to arrive at an incorrect configuration.

[cosmos72]

Because -liconv is added to all linker invocations done by configure script?

That's ugly, as zuo, zlib, lz4, and most linker invocatios from configure don't need it - from what I understand, only the main scheme executable (and possible few other binaries) need it

[mflatt]

Fair point. The practical implications are minimal in this case, since zlib built this way will be statically linked. From a wider perspective, I would say that automatically building a vendored zlib is where things go wrong in principle: using ZLIB= with either system-available libraries or separate builds (supported by something like vpkg if not the OS's package manager) is better. But the vendored approach simplifies the build for many users, and having one LDLIBS is part of that simplification.