Make that the tricky ones will be sparc and m68k.

The easier ones may well be covered by:

https://web.git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=89b0e7a69a07025874b94478efdc5d1280b1704c

I think there is a small chance that this commit adds support for the tricky ones too. However, I am suspicious that __sparc__ is somewhat unique and will require further work.

https://web.git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=bbd88328b2ae291ecdbeac09619d78753917e0d5

Christian says that the place to watch for build status right now is:

https://buildd.debian.org/status/package.php?p=libcap2&suite=experimental

logging this here so I can keep an eye on that page.

m68k appears to build. The other four not.

sparc64 is not a surprise
hppa - Christian says has some build issue so might not be failing for my change

alpha and sh4 didn't work.

I think I'm going to have to build some QEMU system images to debug with.

sh4 looks like it worked here:

https://buildd.debian.org/status/package.php?p=libcap2&suite=sid

Which suggests, all that remain are: alpha, hppa and sparc64

I guess ppc64 is also failing to build.

At this point, on

  https://buildd.debian.org/status/package.php?p=libcap2

We have `alpha` and `sparc64` that are likely still needing more work. I don't have a platform to debug them on. No idea what the `alpha` issue is, but the `sparc64` issue is definitely related to the way signals are handled on that architecture being non-standard.

I believe `x32` is broken, because the build thinks Go is supported, but it isn't an architecture that Go actually supports.

The following targets seem to have some package dependency issue, but I believe they "should work": `hppa`, `sh4` and `m68k`.

libcap-2.76 will be as summarized in the last update.

We also have build issues in Buildroot with the ARC, Microblaze and OpenRISC CPU architectures:

- ARC: http://autobuild.buildroot.net/results/c99/c99f461ac757d2934a353818a302a67ef3ad5cf5/build-end.log
- Microblaze: http://autobuild.buildroot.net/results/8ca/8cae72f02d25a48287320d9c991f41761487e353/build-end.log
- OpenRISC: http://autobuild.buildroot.net/results/74e/74e2c4d37c5b0ae2749c7d77ca7431bd0d510971/build-end.log

I don't have test access to any of these systems at present. I see QEMU on my Fedora box has a qemu-system-microblaze binary, so if I can get some system images to emulate that one, I may be able to resolve that. All of them appear to be failing with the same compilation error, so I might also be able to guess a fix for them and ask for your help to check.

For each of these a={microblaze,arc,openrisc},

In the kernel sources,

a=microblaze ; gcc -I ./arch/$a/include -I ./arch/$a/include/generated -I ./include -I ./tools/include/generated/ -I tools/include -I junk -E ./inc
lude/uapi/linux/signal.h | less -psigaction

suggests these architectures have no SA_RESTORER complexity, so I'll try to guess a fix for them all.

FWIW To get the above to work, you need to first mkdir -p junk/uapi and insert the following two symlinks:

junk/asm -> ../include/asm-generic
junk/uapi/asm -> ../../include/uapi/asm-generic

Are you sure arc does not have SA_RESTORER ? It is definitely defined in the kernel headers:

arch/arc/include/uapi/asm/signal.h:#define SA_RESTORER  0x04000000

I must say I was rather confused by the following code:

#if defined(__x86_64__) || defined(__i386__) \
    || defined(__arm__) \
    || defined(__powerpc__)
/* field used */
#define SA_RESTORER  0x04000000
#endif /* architectures that use SA_RESTORER */

#if defined(SA_RESTORER) \
    || defined(__aarch64__) \
    || defined(__m68k__) || defined(__sh__) || defined(__sparc__) \
    || defined(__s390__) || defined(__sparc__)
/* field defined */
#define _HAS_SA_RESTORER   void *sa_restorer;
#else
#define _HAS_SA_RESTORER
#endif /* architectures that include sa_restorer field */

I am wondering why the set of architectures is not the same in both cases.

Indeed, the kernel code contains:

#ifndef __KERNEL__
struct sigaction {
        __sighandler_t sa_handler;
        unsigned long sa_flags;
#ifdef SA_RESTORER
        __sigrestore_t sa_restorer;
#endif
        sigset_t sa_mask;               /* mask last for extensibility */
};
#endif

Which implies that the sa_restorer field is there as soon as SA_RESTORER is defined on the architecture.

Mmm. Mea culpa. I guess I should have included another include:

a=arc ; gcc -I ./arch/$a/include/uapi -I ./arch/$a/include -I ./arch/$a/include/generated -I ./include -I ./tools/include/generated/ -I tools/inclu
de -I junk -E ./include/uapi/linux/signal.h | less -psigaction

That does find sig_restorer in there. The other two are without it.

Please test this over libcap-2.76:

https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=7a2eee56607218d017af8d26c2c41dba83629708

Let me know if it helps.

Thanks for the fix, I confirm it fixes the build issue on ARC, Microblaze and OpenRISC. I have no idea whether it works at runtime, though. Thanks!

It would be awesome if anyone reading this bug would confirm that:

  make test

works on these architectures. I'm not sure that QEMU is faithfully propagating signals unless run in qemu-system-<arch> version. See https://bugzilla.kernel.org/show_bug.cgi?id=219912 for that issue.

Note that we also have the same build issue with the Xtensa CPU architecture, see https://gitlab.com/jolivain/buildroot/-/jobs/9770003981.

Regarding testing on the target: having the full libcap source code on the target isn't very convenient (Buildroot does not provide a full development environment on the target, with "make", a compiler, etc.). Is there something more minimal than "make test" that will allow to test things on target?

For the libpsx code, this should be sufficient:

$ make -C tests run_psx_test

I think this should add xtensa support:

https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=6cdd8cd72ebcedd6b1b6c989a7e5722d5d87f35c