fix(main/fish): rename tarball version file to avoid conflict with NDK internal version file

[robertkirkman]

Progress on #21130

Fixes /home/builder/.termux-build/fish/src/version:1:1: error: expected unqualified-id in build of fish package.

This seems to be a completely independent issue from most other issues because it is reproducible in a clean repo using this command:

scripts/run-docker.sh ./build-package.sh -I fish

but I did not create a separate issue since it has not yet been marked as fixed in #21130.

I also tried temporarily unapplying the line
grep -lrw $_TERMUX_TOOLCHAIN_TMPDIR/sysroot/usr/include/c++/v1 -e '<version>' | xargs -n 1 sed -i 's/<version>/\"version\"/g' from the end of termux_setup_toolchain_27b.sh and deleting the ~/.termux-build/_cache in case it made any difference, but at least in my test, it did not seem to make a difference on the fish package (whether or not #include "version" or #include <version> is forced in the toolchain) so, it seems like the fish package itself has to be patched.

[robertkirkman]

I tried to check what other distros do for this, since I don't understand why this started happening if fish for Termux successfully built previously. Unfortunately this could be uncharted territory because I don't see any distros that support a remotely similar toolchain codepath that also have a fish package.

• emerge-aarch64-gentoo-linux-musl fish command on Gentoo uses clang (LLVM) to cross-compile from GNU host to alternative libc target, but fails before this point because Gentoo does not yet support C++ code and musl-libc simultaneously (manifests as aarch64-gentoo-linux-musl-clang can successfully compile code but aarch64-gentoo-linux-musl-clang++ cannot until some future updates)
• Chimera Linux is built using LLVM and musl including C++ support and does have a fish-shell package, but I was unable to build any of its source packages due to this error: bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'. it looks like fixing that error takes a lot of setup on non-Debian host so it's probably necessary to use a different distro than Chimera Linux with a more traditional build toolchain to see an apples-to-apples comparison.
• Alpine Linux uses gcc-libs to implement C++ STL, instead of LLVM (aka uses libstdc++ instead of libc++), though it does have a version file and instances of #include <version> in it, so I don't yet understand how Alpine Linux's fish package and other libstdc++-based distros' fish packages don't encounter this error.

# alpine linux
/home/electric-boogaloo/aports/main/fish $ grep -rn /usr/include/c++/13.2.1/  -e "#include <version>"
/usr/include/c++/13.2.1/x86_64-alpine-linux-musl/bits/stdc++.h:92:#include <version>
/usr/include/c++/13.2.1/x86_64-alpine-linux-musl/bits/stdc++.h:220:#include <version>
/home/electric-boogaloo/aports/main/fish $ abuild -r # success

It would be great to find the true root cause by finding whether there are any distros in which this include order of version file problem between fish and LLVM libc++ can be reproduced and identifying exactly what that distro and Android have in common that causes it, but until then I don't have any other idea how to fix this error.

• reproducible regardless of whether [RFC] fix $TERMUX_PREFIX pollution #21835 is applied or not, so unrelated to that and not fixable by it
• reproducible with cross-compilation disabled (./build-package.sh -I fish on device)

[TomJo2000]

It would be good if you could test if this is still an issue when building against the 27c toolchain, though I suspect it is.
I think in the meantime this is a sensible workaround until we can rootcause and solve the issue more "properly."

Edit: Yep just checked, still occurs with 27c.