~aman/static-opus-tools

095dd9681412fd36391703a69fc2ee1334539297 — Aman Verma 2 months ago 97df5c9
Big update to README: unify with static-mozjpeg.
1 files changed, 45 insertions(+), 14 deletions(-)

M README.md
M README.md => README.md +45 -14
@@ 1,4 1,11 @@
# Build opus-tools statically
# Build various encoding tools statically

This project contains 2 repos: one to do a static build of opus-tools and flac,
and another to do a static build of mozjpeg.

## Instructions

### Build opus-tools and flac statically

This is simply a script to do a static build of opus-tools (and flac) on Linux.
Run it inside a musl-based Linux distribution like Void or Alpine. It grabs the


@@ 6,40 13,64 @@ latest releases of libogg, libflac, libopus, and libopusfile and grabs the git
masters of opus-tools and libopusenc. There is also a Dockerfile based on the
script that you can run if you aren't on a musl-based Linux distribution.

The Docker workflow is

    docker build
    docker cp <name>:/usr/local/bin/ <output_dir>

### Build mozjpeg statically

This is simply a script to do a static build of the latest git master of mozjpeg on
Linux. It is somewhat nontrivial for anyone not used to CMake, so I decided to share
this. You have to run it inside a musl-based Linux distribution because glibc
isn't great for static linking. There is also a Dockerfile based on the
script that you can run if you aren't on a musl-based Linux distribution.

The Docker workflow is

    docker build
    docker cp <name>:/home/builder/mozjpeg/build/ <output_dir>

## How to verify the binaries attached in the releases

You can verify the integrity of the attached files with minisign or signify. First,
download my public key file from one of the many places I have uploaded it:
[GitHub][gist], [sr.ht][paste], or [mastodon][toot]. Next, compare the public keys from
at least 2 different places and make sure they are identical. If they aren't, that could
mean one of my accounts has been hacked. Finally, run
You can verify the integrity of the attached files with minisign or signify.
First, download my public key file from one of the many places I have uploaded
it: [GitHub][gist], [sr.ht][paste], [mastodon][toot], or [my website]. Next,
compare the public keys from at least 2 different places and make sure they are
identical. If they aren't, that could mean one of my accounts has been hacked.
Finally, run

    signify -C -p <pubkey> -x SHA256SUMS.sig
    signify -C -p <pubkey> -x [possible prefix]SHA256SUMS.sig

where `<pubkey>` is the public key file you downloaded and cross-checked earlier. If
you downloaded all the attached executables, you should get

    Signature Verified
    flac: OK
    metaflac: OK
    opusdec: OK
    opusenc: OK
    opusinfo: OK
    <filename>: OK

where `<filename>` is the name of the file(s) you are trying to verify.
If you didn't download all the attached executables, signify will complain with the word
"FAIL" after the filename, but it will still try to verify the ones that exist. If you see
"FAIL" after the name of a file that _does_ exist, or if you see "signify: signature
verification failed", that is **bad** and you should delete the files you downloaded
immediately.

Additionally, the binaries were built on builds.sr.ht, so you can see the log
for the build at <https://builds.sr.ht/~aman/job/301491>.
Additionally, the binaries were built on builds.sr.ht. Read the release notes
to find out where to inspect the log of the build. The script prints out the
checksums for the binaries at the end so you can check them that way too.

[paste]: https://paste.sr.ht/~aman/392dcc7b5e04f047eb6b80addf4f43787e3ff29c
[toot]: https://mastodon.online/web/statuses/104769781342888143
[gist]: https://gist.github.com/a-vrma/969a05ff013e57ff1abd1625a0de9c5f
[my website]: https://aman.raoverma.com/aman_signify.txt

## Todo

MozJPEG:

- Add a Dockerfile for the latest release when they cut a new one.

opus-tools:

- Experiment with LTO (-flto in CFLAGS and LDFLAGS).
- Try compiling with Clang and LLD.