Feedback on Linux

[mshedsilegx]

Not an issue, just a feedback on building for Linux on RHEL8/9/10 in our environment.

7zip_linux_compat.patch.txt
7zip-xg.spec.txt

Thank you again for providing a very nice way to build for Linux, allowing us to replace the unmaintained p7zip-zstd

1- gcc does not work, clang 19/20 is fine
2- I need the so and sfx objects to be located in a separate folder (/usr/libexec/7zip, not collocated with the binaries (/usr/bin)
3- I also need to build the SFX module so that the option -sfx would work

Attached patch and spec file.

[mcmilk]

Should I try to get it upstream in Debian and on Fedora?

[mcmilk]

Regarding gcc - I will check the failures and fix them.

[mshedsilegx]

Absolutely ! It is a great release, well managed and maintained, and much better than the current state of p7zip. Thanks again for all your work. Compiles very cleanly with clang.

[mshedsilegx]

Compiled fine on Ubuntu 24.04 with clang-20. uasm is not packaged in Ubuntu, but the static version from https://www.terraspace.co.uk/uasm257_linux64.zip works well.

[mshedsilegx]

Latest spec and patch, for my RHEL builds. The resulting RPM runs fine in all our production systems 8/9/10.

7zip_linux_compat.patch.txt
7zip-xg.spec.txt

[mcmilk]

You can use gcc/g++ also now.

[sebres]

Well, since ffb575a moved the build folder to another OUTDIR (basically 2 of them, one for gcc another for clang), the test suite did not work at all anymore, but mistakenly succeeded due to error check (unstartable executable, e. g. on cross-platform build if arm is built on x86/x64), but now exited with "no such file or directory" error.

So I made 2 amends for that in current master:

• 76e5f2e illustrates the bug (and therefore intentionally failed) as well as avoid mistaken "success" exit by future errors like that;
• 4e9c08d that fixes test of linux builds (and now tests gcc and clang builds in both folders);

[mcmilk]

Good point, we need a set -e on the bash itself ... so the script will fail on any error.

[sebres]

we need a set -e on the bash itself ... so the script will fail on any error.

No, it will fail in any case (and 76e5f2e illustrates now exactly this BOOM).
The bypass was previously intentional, and it shall still not fail in x64 ARM build, because the executable built for another platform, and ARM binary is not workable on x64 platform.
But it was too loose (since didn't check the error).

So it shall not fail in windows (amd64_arm64) due to wrong platform:
Cannot test using "build\bin-arm64\7z.exe" (invalid platform?): couldn't execute "build\bin-arm64\7z.exe": invalid argument
But shall fail in linux due to wrong path (or other error):
Cannot test using "CPP/build/7z" (invalid platform?): couldn't execute "CPP/build/7z": no such file or directory

What is now fixed in 76e5f2e, so it'd fail in the future if something going wrong by test of executable.

But maybe I don't understand your point with set -e in that context.

[mcmilk]

This script will not print the "hello 2":

#!/bin/bash

set -e

echo "hello 1"
false

echo "hello 2"

set -e is used a lot for this type of error checking
If some cmd is expected to exit != 0 - then it has to be catched via || like this:

#!/bin/bash

set -e

echo "hello 1"
false || echo "Warning: false returns false ;)"

echo "hello 2"

[sebres]

I know that...
But IIRC this is default behavior in shell of workflow step in GHA (in bash)... As well as in tcl-script (if command is intended to fail silently, it must catch the error). So the test step would fail normally (but as already said was intentionally avoided and the check was too loose).
That's why I said that I don't follow your point with set -e in that context.

[mshedsilegx]

Compiles now very cleanly as well with gcc13/14 on EL8/9/10 and Ubuntu 24.04. Thanks again !