Publish static binaries for each GitHub Release about proot-rs

[imlk0]

How about using triples to name them? Because that's basically the same way rust defines its target.
https://doc.rust-lang.org/rustc/platform-support.html
An example of release: https://github.com/sagiegurari/cargo-make/releases

[imlk0]

Okay, I'm trying the first option

[oxr463]

What should we name them? The old static binaries were as follows:

• x86
• x86_64
• arm
• arm64

See: https://github.com/proot-me/proot-static-build/tree/master/static

[oxr463]

What should we name them? The old static binaries were as follows:

* x86

* x86_64

* arm

* arm64

See: https://github.com/proot-me/proot-static-build/tree/master/static

Looks like x86_64, arm, and aarch64 will work fine. That's how GCC labels them as well:

• https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html#Submodel-Options

[oxr463]

Per Gitter,

https://semver.org/#how-should-i-deal-with-revisions-in-the-0yz-initial-development-phase
I updated the milestone to v0.1.0 instead of v0.0.1
When we are working on GitHub Releases, we can burn through v0.0.x until we get it working, then when we are ready to finish the project, we will publish it as v0.1.0

[oxr463]

How about using triples to name them? Because that's basically the same way rust defines its target.
https://doc.rust-lang.org/rustc/platform-support.html
An example of release: https://github.com/sagiegurari/cargo-make/releases

I like that approach. It's more specific. Let do it!

[imlk0]

How about using triples to name them? Because that's basically the same way rust defines its target.
https://doc.rust-lang.org/rustc/platform-support.html
An example of release: https://github.com/sagiegurari/cargo-make/releases

I like that approach. It's more specific. Let do it!

I agree.

Here are some of these triads that we may publish:

• x86_64-unknown-linux-musl
• x86_64-unknown-linux-gnu
• x86_64-linux-android
• i686-unknown-linux-musl
• i686-unknown-linux-gnu
• i686-linux-android
• armv7-unknown-linux-musleabi
• armv7-unknown-linux-gnueabi
• arm-linux-androideabi
• aarch64-unknown-linux-musl
• aarch64-unknown-linux-gnu
• aarch64-linux-android

The difference between them:

• -musl means statically linked while -gnu is dynamically linked to gnu libc
• -android and -androideabi are built for Android, and they are also dynamically linked.

Do we need to discard some of them, or release for all these 12 triples?

[oxr463]

I agree.

Here are some of these triads that we may publish:

* x86_64-unknown-linux-musl

* x86_64-unknown-linux-gnu

* x86_64-linux-android

* i686-unknown-linux-musl

* i686-unknown-linux-gnu

* i686-linux-android

* armv7-unknown-linux-musleabi

* armv7-unknown-linux-gnueabi

* arm-linux-androideabi

* aarch64-unknown-linux-musl

* aarch64-unknown-linux-gnu

* aarch64-linux-android

The difference between them:

* `-musl` means statically linked while `-gnu` is dynamically linked to gnu libc

* `-android` and `-androideabi` are built for Android, and they are also dynamically linked.

Do we need to discard some of them, or release for all these 12 triples?

Will it take more time to publish all 12? Personally, I'm not interested in the i686 builds, and we probably don't need musl and gnu for each architecture. How do the dynamically linked android targets work?

[imlk0]

Will it take more time to publish all 12?

It will be longer but I think will still be acceptable.

Personally, I'm not interested in the i686 builds, and we probably don't need musl and gnu for each architecture.

Although x64 is now more popular than x86, some people may still need a x86 build, so I suggest keeping x86 here.
Yes, we may need to choose between musl and gnu.

How do the dynamically linked android targets work?

If building for Android, the PT_INTERP will be set to /system/lib/linker, the path of dynamic libraries will also be changed to /system/lib/, which is done by Android NDK toolchain.
Although the -linux-musl built can also run on Android, I still recommend keeping the -android build since they seem to have some slight differences.

[oxr463]

Will it take more time to publish all 12?

It will be longer but I think will still be acceptable.

Personally, I'm not interested in the i686 builds, and we probably don't need musl and gnu for each architecture.

Although x64 is now more popular than x86, some people may still need a x86 build, so I suggest keeping x86 here.
Yes, we may need to choose between musl and gnu.

How do the dynamically linked android targets work?

If building for Android, the PT_INTERP will be set to /system/lib/linker, the path of dynamic libraries will also be changed to /system/lib/, which is done by Android NDK toolchain.
Although the -linux-musl built can also run on Android, I still recommend keeping the -android build since they seem to have some slight differences.

If you are able to publish all 12 then I would welcome it.

Otherwise, would you please present a shortened list? I trust your judgement.