My build system only supports static building of libcap with musl-gcc. It was mentioned in this gentoo bug https://bugs.gentoo.org/show_bug.cgi?id=820071 that musl builds were segfaulting when running libcap.so. Since I've never before attempted to support any .so build for musl, this isn't at all surprising. This bug is to fully support musl builds of all the shared objects in the libcap tree. Sam James provided a Dockerfile for exploring: -------8<------ FROM gentoo/stage3:musl RUN emerge-webrsync -q RUN emerge --quiet --quiet-build=y dev-vcs/git RUN git clone -q https://git.kernel.org/pub/scm/libs/libcap/libcap.git CMD /bin/sh -c 'cd libcap && make clean COPTS="-O0 -g -ggdb3" -C libcap all test' -------8<------
Big thanks for debugging the other issues too. Really appreciated. There's something else interesting here too. I tried with Alpine which is shipping gcc 10 in stable (Gentoo is now using gcc 11 by default, although you can still get gcc 10) and it worked: ``` FROM alpine:edge RUN apk update \ && apk --no-cache --update add build-base libcap libcap-dev git perl RUN git clone https://git.kernel.org/pub/scm/libs/libcap/libcap.git CMD /bin/sh -c 'cd libcap && make clean COPTS="-O3 -g -ggdb3" -C libcap all test' ``` But that doesn't rule it out being musl-related. Just that it might be worth playing with compiler version. I haven't explored if there's a convenient way to get GCC 11 in that Alpine container.
So, it turns out, it is the same issue. For some reason I can't figure out the musl gcc for x86_64 does not ensure that all function definitions are implicitly honoring the 16 byte alignment requirement. I could put a whole bunch of hackery in to figure out if we're compiling with respect to musl but the simplest thing is to force both __i386__ and __x86_64__ architectures to both force align the main() stack.
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=e9414f540a82b5348a12cfaddff229241564e1f3
Note, inside the container #c0 make SUDO=" " clean all test sudotest seems to work now.