search

proot-me / proot-rs

Rust implementation of PRoot, a ptrace-based sandbox
GNU General Public License v3.0
129 stars 21 forks source link

Publish static binaries for each GitHub Release #52

Closed oxr463 closed 3 years ago

oxr463 commented 3 years ago

Architectures:

Originally posted by @oxr463 in https://github.com/proot-me/proot-rs/issues/35#issuecomment-896836738

oxr463 commented 3 years ago

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

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

oxr463 commented 3 years ago

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:

oxr463 commented 3 years ago

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

imlk0 commented 3 years ago

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

oxr463 commented 3 years ago

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 commented 3 years ago

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:

The difference between them:

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

oxr463 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.

imlk0 commented 3 years ago

Okay, I'm trying the first option