The optimised version of 7-Zip can't be built from source | Hacker News Reader

The optimised version of 7-Zip can't be built from source

pileofhacks.dev

49 pointstodsacerdoti26 comments

It's incredible the number of people who do not know how to read an open-source licence.

> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

I also think a more correct title should be "I could not build 7-zip from source", as they correctly acknowledge in the end.

> Ugh. This is a bit beyond my knowledge to fix

> In the same thread from the author, they mention that asmc is a fork of JWasm 4, which was written in C. Maybe it’s as “easy” as swapping out one for the other - using gcc to build jwasm, then using jwasm to build asmc?

You can probably skip that and use one of the nasm-compatible assemblers directly with 7zip's build process instead...

> Even if I did want to use the prebuilt version, it’s dynamically linked to glibc so won’t work on alpine.

I imagine the gcompat package will get it running.

https://wiki.alpinelinux.org/wiki/Running_glibc_programs

The 7-zip code does admittedly scare me a bit at times, but the fact that it can be a pain to build isn't really that big of an issue. A lot of stuff is a pain to build. Like Chromium.

Dealing with people like this is why many don't want to open source their code. Take it or leave it.

The title distracts from the actual conclusion of the blog post, namely that it is apparently hard to build projects that include assembly on something called Alpine Linux.

If all that's missing is 'a nasm compatible assembler', did they try just swapping it out for nasm, which seems to have a readily available alpine package?

https://pkgs.alpinelinux.org/package/edge/main/x86/nasm

Don't get me wrong, OSS does not mean it will build in any random configuration on any distro. The source is there. Maybe 7zip could do better, but still...

> writes "nasm compatible assembler" like it's some dark incantation

> "i'm not going to argue, i can't read assembly and i don't want my built to be slow"

> i'm going to use a highly non-standard distro that's known to have serious build problems because it uses an alternate libc

> "this is a bit beyond my knowledge to fix"

why would igor pavlov do this???

joking aside there's literally a nasm package built for alpine. he could have just aliased asmc to it and 7z probably would have built fine.

The author doesn't mention if they considered switching to a glibc container to fix the lack of glibc. That seems a reasonable solution rather then swapping out the complete assembly compiler.

You can't build modern Rust without a rustc binary... Does that mean it "can't be built from source"?

I would be shocked if the rust documentation didn't explain very clearly how to bootstrap rustc starting from gcc

Prepare yourself for a shock then; bootstrapping rustc starts from an already-built version of rustc[1]:

> the only way to build a modern version of rustc is a slightly less modern version.

(There is, at least theoretically, a non-circular bootstrap chain starting with a very old rustc written in OCaml, but the more practical alternative is probably to use mrustc[2] instead.)

[1] https://rustc-dev-guide.rust-lang.org/building/bootstrapping...

[2] https://guix.gnu.org/en/blog/2018/bootstrapping-rust/

Ocaml has a bytecode blob in the sources (even checked into Git). It uses that to resolve its own bootstrap problem. If you aim for a source-only starting point, your journey won't stop at Ocaml.

Then you need to build GCC without GCC.

That is possible too:

https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-... https://bootstrappable.org/ https://lwn.net/Articles/983340/

The GCC project wants it to be possible to build GCC with a C++11 compiler that is not GCC.

I mean.. that is absolutely something the bootstrap/reproducibility folks would flag as a problem. Heck, https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-... went to great extremes to bootstrap a C compiler through the all-important gcc 4.9 (which comes up constantly in these efforts because it was the last gcc that builds without a C++ compiler).

It does provide a neat way to hide a supply line attack. C.f. http://wiki.c2.com/?TheKenThompsonHack

Lovely path to hide self-propagating malware then

Til 7z posts quarterly sources in archives. We'll that's a bit sketchy

What's sketchy? It's a less common model these days, but GNU traditionally did that.

Same thing happens with Bash: The guy pukes out a new tarball or a new diff every few months if he feels like it.

And again: What's wrong with that?

Keeping a clean, public vcs is a pain in the neck. If you're working on anything less than a large open-source project with many devs and random contributions, it's a pointless hassle. Can you tell me how that makes it any sketchier than leaving a public github?

Public Github with CI means the binary was built unmodified from source. You can turn off issues/PR and push only release branches with squashed commits.

Assuming you trust Github, of course. I think if someone is seriously worried code has been altered between source and maintainer-provided binary, his big concern will be the time it takes to audit the source code (which he also shouldn't trust). The build time will be inconsequential next to that.

The Reproducible Builds project is working on trustworthy builds:

https://reproducible-builds.org/

Reply on news.ycombinator.com