When upgrading libcap from 2.51 to 2.52, our clang build started complaining with: ``` /toolchain/host-llvm-10.0.1-x86_64-linux-1/bin/objcopy --dump-section .interp=/dev/stdout empty > loader.txt /toolchain/host-llvm-10.0.1-x86_64-linux-1/bin/objcopy: error: 'empty': Permission denied ``` This problem seems to be fixed by changing this rule in `libcap/Makefile`: ``` loader.txt: empty $(OBJCOPY) --dump-section .interp=/dev/stdout $< > $@ ``` to this: ``` loader.txt: empty $(OBJCOPY) --dump-section .interp=$@ $< ``` However, that only uncovers the next build error: ``` clang-10: error: unsupported option '--entry=__so_start' ``` which I suspect is related to this section in the same `libcap/Makefile`: ``` # The linker magic needed to build a dynamic library as independently # executable MAGIC=--entry=__so_start ``` Any ideas on how to fix this for clang? Or how to easily disable this feature when building with clang?
Thanks for this bug report. To date, I've never actually looked into supporting clang. However, this bug suggests it was mostly working before this latest release, so I'll set up a testing environment and try to figure out how to make it work.
While I figure out how to set up clang builds, you might like to try replacing '--entry=__so_start' with '-Wl,-e,__so_start'.
Please see this commit: https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=6dea1813f269f9c03cea226fffdd75670c70ea01 Reopen if that doesn't address your needs.
Can confirm that your commit resolves this issue for us as well. Appreciate the quick turnaround, and thanks for your time!