Great to see another (stable) release. I wanted to ask a few things: Is there any intention to include the following two patches from Debian - one and two. Would you be able to offically support UASM in the Linux Makefile? UASM is a free MASM-compatible assembler based on JWasm - however unlike JWasm it supports AES instructions. The only difference is you need to turn off the automatic stack optimisations by prefixing all ASM files with: OPTION FRAMEPRESERVEFLAGS:ON OPTION PROLOGUE:NONE OPTION EPILOGUE:NONE...
Take a look at this: https://github.com/justdan96/7zip_static/releases/tag/21.03beta
It definitely won't be fast - but it would at least be functional. Perhaps as a compromise 7-Zip could check if the RAM and the RAM + Swap is enough for the operation. + If the RAM alone is enough, the operation passes through. + If the RAM + Swap is enough display a warning that the operation would be slow and suggest to decrease dictionary size, but allow the user continue if they choose. + If the RAM + Swap is not enough display the error, as it does now.
It definitely won't be fast - but it would at least be functional. Perhaps as a compromise 7-Zip could check if the RAM and the RAM + Swap is enough for the operation. If the RAM alone is enough, the operation passes through. If the RAM + Swap is enough display a warning that the operation would be slow and suggest to decrease dictionary size, but allow the user continue if they choose. * If the RAM + Swap is not enough display the error, as it does now.
Does the error take into account swap? If the user has 8GB RAM but 12GB swap will 7-Zip know it can use 20GB of memory?
It might depend on perspective - UASM implemented smart stack alignment and it is enabled by default. I think that is reasonable but in this case we don't want it, perhaps it trips up as we aren't creating an ASM program but rather using a snippet? I couldn't find a way to disable those options on the command line so for now we have to prepend all the ASM files with those options. Either way ASMC has taken their Linux releases offline so it looks like we can't rely on ASMC and we have to ensure UASM...
UASM developers have said there is an option to disable stack alignment, based on this bug report: https://github.com/Terraspace/UASM/issues/118 I also checked the documentation here: http://www.terraspace.co.uk/uasm251_ext.pdf I used to following to prefix the ASM file with the options we want: sed -i -e '1i\OPTION FRAMEPRESERVEFLAGS:ON\nOPTION PROLOGUE:NONE\nOPTION EPILOGUE:NONE' Asm/x86/LzFindOpt.asm When the Asm file is compiled it then produces a file exactly the same as the ASMC output. Edit:...
UASM developers have said there is an option to disable stack alignment, based on this bug report: https://github.com/Terraspace/UASM/issues/118 I also checked the documentation here: http://www.terraspace.co.uk/uasm251_ext.pdf I used to following to prefix the ASM file with the options we want: sed -i -e '1i\OPTION FRAMEPRESERVEFLAGS:ON\nOPTION PROLOGUE:NONE\nOPTION EPILOGUE:NONE' Asm/x86/LzFindOpt.asm When the Asm file is compiled it then produces a file exactly the same as the ASMC output.
You could also pick up the sources from Debian Salsa: https://salsa.debian.org/yokota/7zip/-/tree/upstream/21.02 But you may want to wait until a release has been created. Edit: Sorry I think the correct repo is https://salsa.debian.org/debian/7zip/-/tree/upstream/21.02_alpha
You could also pick up the sources from Debian Salsa: https://salsa.debian.org/yokota/7zip/-/tree/upstream/21.02 But you may want to wait until a release has been created.
It looks like someone is working on this already: https://github.com/jinfeihan57/p7zip/tree/7zip_21.02
Okay so it is a behaviour change but a reasonable one. The only issue is that the double full stops are being output in the extracted folder name, which I assume we wouldn't want. It also means the folder is being hidden on Linux. Would it be possible to strip those out from the beginning of the name? I know this seems to be an edge case as I tested with lots of other DMG files and none of them seem to have this structure but it would still be nice to have.
I think I may have found either a bug or a difference in behaviour, it appears that extracting a DMG file the output paths can be altered slightly. You can test the following DMG file: https://www.videohelp.com/download/tsMuxeR_2.6.11.dmg Older versions extract a folder called "install", 21.02 alpha extracts a folder called ".._install_tsMuxerGUI". It looks like the path separators are being replaced with underscores in later versions: p7zip Version 16.02: ../install/tsMuxerGUI 7-Zip 21.02 alpha:...
I think based on this blog post this actually is a behaviour change, sched_setaffinity is for the process whereas pthread_setaffinity_np and pthread_attr_setaffinity_np is for a thread.
I think I may have found either a bug or a difference in behaviour, it appears that extracting a DMG file the output paths can be altered slightly. You can test the following DMG file: https://www.videohelp.com/download/tsMuxeR_2.6.11.dmg Older versions extract a folder called "install", 21.02 alpha extracts a folder called ".._install_tsMuxerGUI"
I had the same issue, luckily someone mentioned that you can use bsdtar to unzip the sources: https://github.com/justdan96/7zip_static/blob/main/Dockerfile
If you aren't bothered about warnings you can use: make CC=$CC CXX=$CXX CFLAGS_BASE_LIST="-c -D_7ZIP_AFFINITY_DISABLE=1 -march=armv8-a+crc+crypto" CFLAGS_WARN_WALL="-Wall -Wextra" -j -f ../../cmpl_gcc_arm64.mak 2> c_arm64.log But it looks like your system can't find the pthread library, can you check where libpthread.so resides (assuming you are not compiling as static)?
The instructions mention cmpl_gcc_arm64.mak, have you tried using that Makefile? You can override variables specified in the Makefile by putting them after the make command, i.e.: make CC=$CC CXX=$CXX -j -f ../../cmpl_gcc_arm64.mak
Seeing as the patch file I am using is a "good enough" solution for UASM on Linux at the moment I might just update the Dockerfile to apply the patch against v2.52 instead - I don't want to mess around with an incomplete version.
Here is a Dockerfile for compiling 7-Zip 21.02 alpha with static linking on Alpine Linux using both Clang and GCC: https://github.com/justdan96/7zip_static I'll add steps for a 32-bit build soon.
UASM works flawlessly for compiling 7-Zip and it seems to be easier to compile than Asmc - maybe you can mention both in the compiler instructions?
Another thing - it would be easier for distribution maintainers if the source code was distributed either in a VCS or as a tar.gz file. It is just that otherwise you need 7-zip to compile 7-zip - you see the issue :)
I've just successfully compiled a statically-linked binary of 7zip 21.02 alpha on Alpine Linux using both Clang and GCC - as well as UASM for the assembler. I will link the Dockerfile I used soon, so other people can see what I have done.
If the binary used musl and was statically linked that would resolve that issue, right?
Uploading my benchmarks, Xubuntu 20.04.2 LTS, kernel 5.4.0-71-generic Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz I would echo comments of others on here that using a Docker container to compile would help with managing dependencies. You could use something like an Alpine container to help create static binaries. Once the source is released an OpenBuildService workflow could be used to create packages for different distributions and if there are still dependencies you'd like to deal with in a distribution-agnostic...
Uploading my benchmarks, Xubuntu 20.04.2 LTS Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz I would echo comments of others on here that using a Docker container to compile would help with managing dependencies. You could use something like an Alpine container to help create static binaries. Once the source is released an OpenBuildService workflow could be used to create packages for different distributions and if there are still dependencies you'd like to deal with in a distribution-agnostic way you could...