ERROR: Version mismatch between libllvm and flang. libllvm=20.1.7:1, flang=20.1.7:0
Should i apply TERMUX_PKG_REVISION to flang as well? I guess so.
Edit: I added it to flang.

Very good idea! I really think this is a very cool idea and I hope it works.

There is just one potential problem, which is that I am pretty sure some applications that are packaged in Termux cannot work properly if there are relative paths in some of their internal directories.

When it finishes I will try testing your PR and I will let you know what happens and if anything has an error!

@robertkirkman Glad that you liked the idea.

There is just one potential problem, which is that I am pretty sure some applications that are packaged in Termux cannot work properly if there are relative paths in some of their internal directories.

I think that there should be no problems because llvm automaticlly converts the sysroot to absolute path.
From https://reviews.llvm.org/D76653#change-zuw0O32XbYXO:

if ((!SysRoot.empty()) && llvm::sys::path::is_relative(SysRoot)) {
    // Prepend InstalledDir if SysRoot is relative
    SmallString<128> P(InstalledDir);
    llvm::sys::path::append(P, SysRoot);
    SysRoot = std::string(P);
}

SysRoot is set to the absolute path. So there shouldn't be any side effects.
But feel free to correct me if i am wrong.

The CI finally finished .. After only 5 hours 🥴

The CI finally finished .. After only 5 hours 🥴

That is to be expected.

Busy with this? Ewww!

https://forums.swift.org/t/announcing-the-android-workgroup/80666

That's alright. Take your time.

Before this and even now, this is assuming that usr merge format is being used, and $TERMUX__ROOTFS != $TERMUX__PREFIX, otherwise default path would get set to parent directory of rootfs. Relative path should be set depending on if they are equal or not.

I assume lib/ and usr/lib/ paths under sysroot are both looked by llvm.

• termux-packages/scripts/properties.sh

  Line 863 in ebcef90

  ##

Busy with this?

Let us know when the rewrite of Termux-app in Swift starts, looking forward to trying it. 😛

Eww eww ewww!!! Don't even say those words! Gosh!

Before this and even now, this is assuming that usr merge format is being used, and $TERMUX__ROOTFS != $TERMUX__PREFIX, otherwise default path would get set to parent directory of rootfs. Relative path should be set depending on if they are equal or not.

I assume lib/ and usr/lib/ paths under sysroot are both looked by llvm.

I don't think that i completely understand but is this right?

When it is installed inside /system/bin the sysroot should be /system maybe?
Is this what do you mean or did i completely get it wrong?

I tried to search for usages for TERMUX__ROOTFS inside packages to understand better but I didn't find any

I have seen certain forks use something like /data/data/com.termux/files/{bin,home,lib} and there is no usr directory. That normally shouldn't be used as distros have moved to usr merge format, where /bin is symlink to /usr/bin, etc. We have always used the right structure so didn't need to switch.

• https://wiki.debian.org/UsrMerge

So if both TERMUX__PREFIX and TERMUX__ROOTFS are set to /data/data/com.termux/files, then going up two directories from /data/data/com.termux/files/bin would use /data/data/com.termux as sysroot instead of /data/data/com.termux/files.

So if prefix and rootfs are equal, then go one directory up .., otherwise two ../... That should probably work.

When it is installed inside /system/bin the sysroot should be /system maybe?

Yes.

I tried to search for usages for TERMUX__ROOTFS inside packages to understand better but I didn't find any

Yeah, rootfs variable isn't really used other than some termux internal packages as it was recently added and packages are more concerned with bin/lib, etc and those are referred by prefix variable.

@agnostic-apollo I applied the changes that you suggested.

if [ "$TERMUX__PREFIX" = "$TERMUX__ROOTFS" ]; then
    DEFAULT_SYSROOT=".."
else
    DEFAULT_SYSROOT="../.."
fi

Thanks, that should work, I'll let package maintainers test it further.

@finagolfin Sorry for the ping. But what do you think?
I also think that the binaries run path should be relative to $ORIGIN
(Kinda like how you used patchelf to patch the run path on https://github.com/finagolfin/swift-android-sdk ;) )

Finally, copy libc++_shared.so from the NDK and modify the cross-compiled Swift corelibs to include $ORIGIN and other relative directories in their rpaths:

cp /home/yourname/android-ndk-r27c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so swift-release-android-aarch64-24-sdk/usr/lib
patchelf --set-rpath $ORIGIN/../..:$ORIGIN swift-release-android-aarch64-24-sdk/usr/lib/swift/android/lib*.so

I'll take a look this week, got delayed.

OK, got some time today, will take a look.