GNU bug report logs -
#45198
28.0.50; Sandbox mode
Previous Next
Full log
Message #158 received at 45198 <at> debbugs.gnu.org (full text, mbox):
> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Tue, 29 Dec 2020 14:50:56 +0100
> Cc: Bastien <bzg <at> gnu.org>, 45198 <at> debbugs.gnu.org,
> João Távora <joaotavora <at> 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.
This bug report was last modified 3 years and 7 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.