bug#45198: 28.0.50; Sandbox mode

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Tue, 29 Dec 2020 14:50:56 +0100
> Cc: Bastien <bzg@gnu.org>, 45198@debbugs.gnu.org,
>  João Távora <joaotavora@gmail.com>
> 
> I've pushed a modified version of these two patches onto the
> scratch/seccomp branch.

Thank you for working on this.

> It would be great if someone could test whether the Windows build
> still works after that, thanks!

I only skimmed the changes, but I'm already quite sure they will break
the Windows build.

This feature is not relevant to the MS-Windows build of Emacs, at
least currently (I don't think Windows implements equivalent features
in a way that is even remotely similar to GNU/Linux).  So to make sure
the Windows port doesn't break, we must take every measure to avoid
compiling any of the related code on MS-Windows.  In particular:

  . Gnulib modules pulled to support seccomp should be disabled in the
    MS-Windows build, by suitable changes to nt/mingw-cfg.site and/or
    nt/gnulib-cfg.mk; and
  . header files used to support seccomp code should be #ifdef'ed by
    HAVE_LINUX_SECCOMP_H or similar, and likewise with any code needed
    for seccomp and unnecessary otherwise.

Btw, I wonder why you needed to import the read-file module from
Gnulib -- does it provide any features that we couldn't implement on
our own?  I'm asking because that module caused you to pull in quite a
few dependency modules from Gnulib, and I'm asking myself whether that
is really justified.