There is an updated pull request by oreo639 against master on the void-packages repository https://github.com/oreo639/void-packages libssp https://github.com/void-linux/void-packages/pull/41294 gcc: disable libssp ~~NOTE: Before this PR can be merged https://github.com/void-linux/void-packages/pull/41229 should be merged first and the cross compilers should finish building completely before this PR is merged.~~ Done. It can be verified using: `XBPS_TARGET_ARCH=... xbps-query -MRX libssp --repository=https://repo-default.voidlinux.org/current/aarch64/musl/ --repository=https://repo-default.voidlinux.org/current/musl/ --repository=https://repo-default.voidlinux.org/current/aarch64/` Edit: I wrote a script here https://gist.github.com/oreo639/ba4dd28e022681467b1239f5375624c8 #### Testing the changes - I tested the changes in this PR: **briefly** There is no reason to have libssp when it is already implemented in the libc. Most distros don't ship it (i.e. Fedora, Arch, Debian, Alpine, etc), for example, Debian stopped shipping it after gcc 4.2. It also breaks qemu-user-static due to function/symbol redefinition errors between glibc and libssp. libssp mostly exists as a fallback implementation. According to Rich Felker: https://gcc.gnu.org/legacy-ml/gcc/2020-01/msg00459.html Q: Should gcc stop trying use musl on i386/powerpc here: ... and fall back to libssp instead? > Absolutely not. libssp is unsafe and creates new vulns/attack surface by doing introspective stuff after the process is already *known to be* in a compromised state. It should never be used. musl's __stack_chk_fail is safe and terminates immediately. All the packages that are bumped in this PR have been compiled. The following needed some changes to fix building: + ~~csync~~ (removed package) + libtls + mozjs91 + mozjs78 + qemu-user-static [ci skip] A patch file from https://github.com/void-linux/void-packages/pull/41294.patch is attached