Open truboxl opened 1 year ago
A possible approach is to include a config.h database. These are files copied from known platforms identified by their target triples.
When cross-compilation is detected, only feature flags (like --enable-vfs) are checked. Other #defines are copied from the database.
Hello @truboxl,
Well, it looks like there are not that many programs that have good support for Canadian Cross setups, where the build, host, and target (or should we say "guest") platforms might all potentially be different.
To allow for {build platform} ≠ {host platform}, a possible fix might be to allow the configure
script to accept an emulator name for host binaries. For now we have
if compile -Werror -o "o/tool/config/${PROGRAM}" "tool/config/${PROGRAM}.c" &&
run "o/tool/config/${RUNPROGRAM}"; then
printf '%s\n' "${MESSAGE} yes" >&2
if [ $# -gt 0 ]; then
"$@"
fi
rc=0
else
printf '%s\n' "${MESSAGE} no" >&2
rc=1
fi
but maybe instead of running "o/tool/config/${RUNPROGRAM}"
directly we could pass it to some Android emulator (?).
Yet another more simplistic alternative might be to skip the run
step — i.e. if a program compiles then just assume the host platform supports the tested feature. I am not quite sure if this is a good idea though.
Thank you!
Contributions welcome
The
configure
script operates on the basis that tests are compiled and run on build machine.config.h
andconfig.mk
are generated so that finalblink
binary works on the build machine.This does not work for Android in which Android NDK are cross compilers.
configure
tests are cross compiled, erroneously run on build machine, failed and disabling all features.Example log: https://github.com/termux/termux-packages/actions/runs/4768306570/jobs/8477478253#step:6:426
My past effort but abandoned: https://github.com/truboxl/termux-packages/pull/88/files https://github.com/truboxl/termux-packages/pull/91/files
Any chance to improve this situation? Will manually intervene
config.h
andconfig.mk
for now downstream...