Comment 1 Sam James 2021-05-10 16:24:12 UTC

build.log too?

Comment 2 Jonas Stein 2021-05-10 23:15:30 UTC

Thank you for the report. We need to have all information at hand before ticket assignment. Please provide
* the complete build.log as attachment and
* paste the emerge info 
as described on https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket

Please reopen this ticket (Status:UNCONFIRMED) afterwards.

Created attachment 707226 [details]
build log

Sorry guys, here it is

Comment 4 Joshua Kinard 2021-06-15 02:06:28 UTC

Affects MIPS as well on an o32 ABI target.  sys-apps/file-5.39 worked fine, so this shouldn't be terribly difficult to hunt down.

Comment 5 Joshua Kinard 2021-06-15 02:34:47 UTC

It looks like this bug was introduced by the fix to Bug #784857, with the addition of the fstatat64 patch.  In the headers installed by sys-apps/libseccomp, 'fstatat64' is just a macro pointing to 'fstatat'.  When the C preprocessor runs and replaces it, that causes the ALLOW_RULE(fstatat64) to become ALLOW_RULE(fstatat), which becomes SCMP_SYS(fstatat), which attempts to look up '__SNR_fstatat', which fails, because '__SNR_fstatat' does not exist, only '__SNR_fstatat64' does.

Kinda thinking this is a bug in libseccomp upstream again, because using a preprocessor macro to clone fstatat64 --> fstatat is the bug.  Temporarily commenting out the patch to add ALLOW_RULE(fstatat64) is a workaround, or just disabling USE seccomp.

Comment 6 Mike Gilbert 2021-06-15 16:27:02 UTC

(In reply to Joshua Kinard from comment #5)

Please attach the header file(s) you are referring to.

Comment 7 Mike Gilbert 2021-06-15 19:50:50 UTC

(In reply to Joshua Kinard from comment #5)
> In the headers installed by
> sys-apps/libseccomp, 'fstatat64' is just a macro pointing to 'fstatat'. 

I don't see this anywhere in the libseccomp headers. Perhaps this happens in the C library headers? Is so, surely this should be fixed there.

Comment 8 Mike Gilbert 2021-06-15 20:12:55 UTC

Created attachment 716361 [details, diff]
seccomp: undef fstatat64 to avoid build failure on musl

Please try this patch.

Thanks Mike, I can confirm with that patch it compiles here on 32bit arm + musl.

Comment 10 Joshua Kinard 2021-06-15 22:50:57 UTC

(In reply to Mike Gilbert from comment #7)
> (In reply to Joshua Kinard from comment #5)
> > In the headers installed by
> > sys-apps/libseccomp, 'fstatat64' is just a macro pointing to 'fstatat'. 
> 
> I don't see this anywhere in the libseccomp headers. Perhaps this happens in
> the C library headers? Is so, surely this should be fixed there.

So I wrote my comment last night in a rush before powerful thunderstorms passed through my area, and I mixed up the headers from libseccomp and the C lib.

It looks like both glibc and musl will redefine fstatat64 --> fstatat, but glibc has a conditional where it will do something else in that circumstance, which I assume must happen on my primary MIPS userland.  But because musl unconditionally makes that redefinition, we hit this bug there.

I'm adding the musl team to see if they happen to have any input.  The undef patch feels really kludgy here.  I'll have to look around the sys-apps/file source code to see if they may have ran into a similar situation before where a __SNR_*64 function was undefined and then corrected for that may apply to fstatat64.

Comment 11 Mike Gilbert 2021-06-15 23:20:14 UTC

(In reply to Joshua Kinard from comment #10)
> I'm adding the musl team to see if they happen to have any input.  The undef
> patch feels really kludgy here.  I'll have to look around the sys-apps/file
> source code to see if they may have ran into a similar situation before
> where a __SNR_*64 function was undefined and then corrected for that may
> apply to fstatat64.

Based on comparing seccomp.c to sys/stat.h in musl, I suspect the following syscalls are also affected:

stat64
fstat64
lstat64

However, the kernel also provides non-64 variants of these calls, so this doesn't result in a build failure.

Comment 12 Joshua Kinard 2021-06-15 23:41:10 UTC

Okay, I *think* I see what's going on here, though I don't fully understand it.

libseccomp's headers (/usr/include/seccomp-syscalls.h) define __SNR_* to either __PNR_* or __NR_*, depending on whether the __NR_* variant exists or not.

For cases where you have similarly-named syscalls like lstat and lstat64, this is handled by defining both of these:

#ifdef __NR_lstat
#define __SNR_lstat                     __NR_lstat
#else
#define __SNR_lstat                     __PNR_lstat
#endif

#ifdef __NR_lstat64
#define __SNR_lstat64                   __NR_lstat64
#else
#define __SNR_lstat64                   __PNR_lstat64
#endif

And musl's sys/stat.h does similar to fstatat by renaming lstat64 --> lstat via macro.  So the lookup just works in those cases.

But fstatat has to be difficult on at least MIPS (and likely ARM as well).  You have newfstatat for the 32-bit version and fstatat64 for the 64bit version, from asm-generic/unistd.h (kernel headers), the __SC_3264 macro is basically defined as __SC_3264(_nr, _64, _32):

#if defined(__ARCH_WANT_NEW_STAT) || defined(__ARCH_WANT_STAT64)
#define __NR3264_fstatat 79
__SC_3264(__NR3264_fstatat, sys_fstatat64, sys_newfstatat)
#define __NR3264_fstat 80
__SC_3264(__NR3264_fstat, sys_fstat64, sys_newfstat)
#endif

This means we simply can't define __PNR_fstatat or __NR_fstatat as 32-bit versions, because they don't exist by that name, but as __NR_newfstatat in kernel headers and __PNR_newfstatat in libseccomp headers.

I am not sure why musl uses the plain "fstatat" name, as it seems like that doesn't really exist for MIPS, but I haven't dug into musl's files yet.

So I've tested a fix that adds this block to /usr/include/seccomp-syscalls.h:

#ifdef __NR_newfstatat
#define __SNR_fstatat                   __NR_newfstatat
#else
#define __SNR_fstatat                   __PNR_newfstatat
#endif

And that looks like it builds on MIPS/musl at least and will execute.  I also tested x86_64/amd64 on glibc, and have a build for MIPS/glibc running as I write this (but it probably won't finish before I am done), but I'll bet it'll fine a basic lookup on /bin/cat just fine.  I wish I had a better way to actually force a test of this syscall, though, to make sure this works and is calling the right syscall.

Patch to be attached for libseccomp's source code, as I am not sure if this is totally correct on other architectures.  There seems to be quite a bit of variability in the definition of this particular syscall's 32-bit and 64-bit versions across archs.

# file /bin/cat
/bin/cat: ELF 32-bit MSB executable, MIPS, MIPS-III version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-mips.so.1, stripped

# file --version
file-5.40
magic file from /usr/share/misc/magic
seccomp support included

Comment 13 Joshua Kinard 2021-06-15 23:45:47 UTC

Created attachment 716373 [details, diff]
Attempt at a fix for the handling of fstatat on MIPS and ARM in libseccomp

Comment 14 Joshua Kinard 2021-06-15 23:52:37 UTC

This seems to be some explanation of the newfstatat syscall in the kernel.  It appears to be unconditionally-defined in most architectures, and seems like it will eventually be superseded by statx in the future, so my fix may not be technically correct (I think), but it may just work regardless.

https://lkml.org/lkml/2018/8/27/663

Definitely no expert on this, and it looks like you're pretty deep in, but you may find it helpful to float this on the musl mailing list, and likely a solution will 'bubble up' fairly quickly. I do shadow the list, and it's quite active!

Comment 16 Joshua Kinard 2021-06-22 21:45:56 UTC

Created attachment 717741 [details, diff]
Fix fstatat/newfstatat handling in sys-libs/libseccomp for some archs

Minor redo of my original patch to put the definitions for __SNR_fstatat under the __NR_newfstatat ifdef check.  This should be safe, as the stat(2) manpage has this to say about things under subsection "C library/kernel differences":

    """
    The underlying system call employed by the glibc fstatat()
    wrapper function is actually called fstatat64() or, on some
    architectures, newfstatat().
    """

I'll file a bug with libseccomp upstream for this, advising them this will fix things when file-5.41 comes out carrying the fstatat64 patch sent to that upstream.

If no one has any issue, I'll add this patch to libseccomp as well as a new -r2 release and drop all keywords to unstable.

Comment 17 Sergei Trofimovich (RETIRED) 2021-06-22 22:14:30 UTC

>  #ifdef __NR_newfstatat
> +#define __SNR_fstatat			__NR_newfstatat
>  #define __SNR_newfstatat		__NR_newfstatat
>  #else
> +#define __SNR_fstatat			__PNR_newfstatat
>  #define __SNR_newfstatat		__PNR_newfstatat
>  #endif

I think that invents a syscall name that is not present on mips (as you have already nuted above). If I grep it correctly it again reaffirm mips only has newfstatat and fstatat64 on all supported ABIs:

"""
$ git grep fstatat | fgrep mips
arch/mips/kernel/syscalls/syscall_n32.tbl:256   n32     newfstatat                      sys_newfstatat
arch/mips/kernel/syscalls/syscall_n64.tbl:252   n64     newfstatat                      sys_newfstatat
arch/mips/kernel/syscalls/syscall_o32.tbl:293   o32     fstatat64                       sys_fstatat64                   sys_newfstatat
tools/perf/arch/mips/entry/syscalls/syscall_n64.tbl:252 n64     newfstatat                      sys_newfstatat
"""

I think the correct fix is not to filter on syscalls that don't exist on 'file' side, not faking non-existent fstatat on libseccomp side. That's only a musl-side build failure (anf glibc is fine), right? Sounds like defines poisoning there.

Comment 18 Sergei Trofimovich (RETIRED) 2021-06-22 22:16:44 UTC

Which CHOST you are using on mips by the way? I'll try to reproduce build failure locally and will poke a bit at it.

Comment 19 Sergei Trofimovich (RETIRED) 2021-06-22 22:40:01 UTC

CHOST=armv6zk-unknown-linux-musleabihf triggers build failure for me as well.

Running file-5.40/src/seccomp.c through '-E -ggdb3' shows us the preprocessor symbol override:

# 70 "/usr/armv6zk-unknown-linux-musleabihf/usr/include/sys/stat.h" 3 4
    #define fstatat64 fstatat

https://git.musl-libc.org/cgit/musl/tree/include/sys/stat.h#n103

That break's file's expansion of 

    #define ALLOW_RULE(call) \
    do \
        if (seccomp_rule_add (ctx, SCMP_ACT_ALLOW, SCMP_SYS(call), 0) == -1) \
            goto out; \
    while (/*CONSTCOND*/0)

    ./src/seccomp.c:        ALLOW_RULE(fstatat64);


I'd say musl headers should not pollute non-underscore namespace like that.

The following seems to make seccomp.c compile:

--- file-5.40/src/seccomp.c_  2021-06-22 23:23:04.017494034 +0100
+++ file-5.40/src/seccomp.c   2021-06-22 23:38:35.803476312 +0100
@@ -181,3 +181,6 @@
 #ifdef __NR_fstatat64
-       ALLOW_RULE(fstatat64);
+    do
+        if (seccomp_rule_add (ctx, SCMP_ACT_ALLOW, SCMP_SYS(fstatat64), 0) == -1)
+            goto out;
+    while (/*CONSTCOND*/0);
 #endif


Maybe 'file' could also inhibit macro expansion in ALLOW_RULE to allow use of literal string in macro expansions?

Comment 20 Joshua Kinard 2021-06-22 22:48:55 UTC

(In reply to Sergei Trofimovich from comment #18)
> Which CHOST you are using on mips by the way? I'll try to reproduce build
> failure locally and will poke a bit at it.

For musl, mips-unknown-linux-musl (O32 ABI), big-endian.

I had a longer response, but Bugzilla's mid-air collision crap ate it.  Let me recompose it...

Comment 21 Joshua Kinard 2021-06-22 23:00:41 UTC

(In reply to Sergei Trofimovich from comment #17)
> >  #ifdef __NR_newfstatat
> > +#define __SNR_fstatat			__NR_newfstatat
> >  #define __SNR_newfstatat		__NR_newfstatat
> >  #else
> > +#define __SNR_fstatat			__PNR_newfstatat
> >  #define __SNR_newfstatat		__PNR_newfstatat
> >  #endif
> 
> I think that invents a syscall name that is not present on mips (as you have
> already nuted above). If I grep it correctly it again reaffirm mips only has
> newfstatat and fstatat64 on all supported ABIs:

It doesn't really create a new syscall name so much as just create a __SNR_ define that's missing on musl/mips.  The problem workflow is basically this:

    sys-apps/file:
    ALLOW_RULE(fstatat64)
       |
    syslibs/musl sys/stat.h (#define fstatat64 fstatat)
    ALLOW_RULE(fstatat)
       |
    sys-libs/libseccomp:
    SCMP_SYS(fstatat)
       |
    __SNR_fstatat (fail!)

This seems to be okay, because musl does define an actual function called fstatat, so the basic symbol lookup will work, but at least mips and arm use "newfstatat" instead of "fstatat".  The two symbol names are interchangable and appear to have the same exact calling conventions, based on the detail in the stat(2) manpage.

mips/glibc does not seem to run into this oddity because glibc's fstatat() wrapper covers up any implementation details, but because musl doesn't do anything fancy like what glibc does, just a basic #define rename, we wind up with the attempted lookup of __SNR_fstatat on mips/musl (and arm/musl).

FWIW, this appears to be fully contained to Linux and its stat(2) syscall mess.  I checked the stat(2) manpage on one of my FreeBSD systems and they appear to be much more sane and consistent with this syscall.

Comment 22 Joshua Kinard 2021-06-22 23:14:59 UTC

(In reply to Sergei Trofimovich from comment #19)
> CHOST=armv6zk-unknown-linux-musleabihf triggers build failure for me as well.
> 
> Running file-5.40/src/seccomp.c through '-E -ggdb3' shows us the
> preprocessor symbol override:
> 
> # 70 "/usr/armv6zk-unknown-linux-musleabihf/usr/include/sys/stat.h" 3 4
>     #define fstatat64 fstatat
> 
> https://git.musl-libc.org/cgit/musl/tree/include/sys/stat.h#n103
> 
> That break's file's expansion of 
> 
>     #define ALLOW_RULE(call) \
>     do \
>         if (seccomp_rule_add (ctx, SCMP_ACT_ALLOW, SCMP_SYS(call), 0) == -1)
> \
>             goto out; \
>     while (/*CONSTCOND*/0)
> 
>     ./src/seccomp.c:        ALLOW_RULE(fstatat64);
> 
> 
> I'd say musl headers should not pollute non-underscore namespace like that.
> 
> The following seems to make seccomp.c compile:
> 
> --- file-5.40/src/seccomp.c_  2021-06-22 23:23:04.017494034 +0100
> +++ file-5.40/src/seccomp.c   2021-06-22 23:38:35.803476312 +0100
> @@ -181,3 +181,6 @@
>  #ifdef __NR_fstatat64
> -       ALLOW_RULE(fstatat64);
> +    do
> +        if (seccomp_rule_add (ctx, SCMP_ACT_ALLOW, SCMP_SYS(fstatat64), 0)
> == -1)
> +            goto out;
> +    while (/*CONSTCOND*/0);
>  #endif
> 
> 
> Maybe 'file' could also inhibit macro expansion in ALLOW_RULE to allow use
> of literal string in macro expansions?

That's a bit kludgy I think.  You're basically sticking the underlying macro for ALLOW_RULE in there, so if the upstream file maintainers ever change/tweak that macro, they now have to do it in at least two places instead of one.  That reduces code maintainability and may be rejected by file's maintainer.

Doing some digging, I saw some references that this same problem will happen with the prlimit64 syscall, because after the transformations, __SNR_prlimit fails to resolve on some musl targets.  I tested this by adding ALLOW_RULE(prlimit64) to file's src/seccomp.c, and it does indeed fail.  However, the fix for that looks like it'll be different than for fstatat64.  But a patch at the below URL suggests using #pragma pop_macro instead of ALLOW_RULE() for Debian's apt tool on musl targets.  Not sure if that code can be leveraged for use in file instead:
https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg148020.html

Comment 23 Joshua Kinard 2021-06-22 23:52:26 UTC

Created attachment 717747 [details, diff]
Hide fstatat64 define on musl

So I looked at what openembedded was doing in Debian's apt source, and replicated that for sys-apps/file.  Not sure that I need the bottom hunk, as file wraps almost everything in src/seccomp.c in a #ifdef HAVE_LIBSECCOMP macro and has nothing outside of that clause.  But I reverted my change to libseccomp and tested this approach instead, and it also compiles on musl/mips and passes file's test suite.

Still kinda partial to my first workaround, but this one comes from another upstream source which works with musl and seccomp a fair bit more, so this might be the better fix.

Link to the original patch for apt:
https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-devtools/apt/apt/0001-Hide-fstatat64-and-prlimit64-defines-on-musl.patch

Comment 24 Joshua Kinard 2021-06-22 23:56:14 UTC

(In reply to Joshua Kinard from comment #23)
> Created attachment 717747 [details, diff] [details, diff]
> Hide fstatat64 define on musl
> 
> So I looked at what openembedded was doing in Debian's apt source, and
> replicated that for sys-apps/file.  Not sure that I need the bottom hunk, as
> file wraps almost everything in src/seccomp.c in a #ifdef HAVE_LIBSECCOMP
> macro and has nothing outside of that clause.  But I reverted my change to
> libseccomp and tested this approach instead, and it also compiles on
> musl/mips and passes file's test suite.
> 
> Still kinda partial to my first workaround, but this one comes from another
> upstream source which works with musl and seccomp a fair bit more, so this
> might be the better fix.
> 
> Link to the original patch for apt:
> https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-
> devtools/apt/apt/0001-Hide-fstatat64-and-prlimit64-defines-on-musl.patch

The only corner case I think this may cause problems with is a third libc, like uclibc-ng.  I don't support that target on mips anymore due to a very weird bug that killed my chroot, but I would feel more comfortable if there was a musl-specific macro that could be checked for instead of checking for anything not glibc.

Comment 25 Sam James 2021-06-22 23:57:28 UTC

(In reply to Joshua Kinard from comment #24)
> 
> The only corner case I think this may cause problems with is a third libc,
> like uclibc-ng.  I don't support that target on mips anymore due to a very
> weird bug that killed my chroot, but I would feel more comfortable if there
> was a musl-specific macro that could be checked for instead of checking for
> anything not glibc.

Bad news: https://wiki.musl-libc.org/faq.html#Q:-Why-is-there-no-%3Ccode%3E__MUSL__%3C/code%3E-macro?

Comment 26 Joshua Kinard 2021-06-23 00:06:03 UTC

(In reply to Sam James from comment #25)
> (In reply to Joshua Kinard from comment #24)
> > 
> > The only corner case I think this may cause problems with is a third libc,
> > like uclibc-ng.  I don't support that target on mips anymore due to a very
> > weird bug that killed my chroot, but I would feel more comfortable if there
> > was a musl-specific macro that could be checked for instead of checking for
> > anything not glibc.
> 
> Bad news:
> https://wiki.musl-libc.org/faq.html#Q:-Why-is-there-no-%3Ccode%3E__MUSL__%3C/
> code%3E-macro?

Well, if we go with this fix and someone running a working uclibc-ng setup runs into it, we can add a check in for __UCLIBC__ anyways.  uclibc-ng has a habit of cribbing logic from glibc anyways, so odds are likely they would fall into the glibc case by default.

Comment 27 Mike Gilbert 2021-06-23 13:43:26 UTC

(In reply to Sergei Trofimovich from comment #19)
> Maybe 'file' could also inhibit macro expansion in ALLOW_RULE to allow use
> of literal string in macro expansions?

I have been looking for a way to "inhibit macro expansion", but found nothing useful. Do you know something that I do not.

Comment 28 Mike Gilbert 2021-06-23 13:46:35 UTC

Comment on attachment 717747 [details, diff]
Hide fstatat64 define on musl

I really think you are making this way too complicated. There's really no need to push/pop macros in a C source file that does not use said macro and does not get #included in other source files.

If you remove the weird GLIBC check and the push/pop, you end up with the patch I had originally proposed:

#undef fstatat64

Comment 29 Joshua Kinard 2021-07-01 23:57:17 UTC

(In reply to Mike Gilbert from comment #28)
> Comment on attachment 717747 [details, diff] [details, diff]
> Hide fstatat64 define on musl
> 
> I really think you are making this way too complicated. There's really no
> need to push/pop macros in a C source file that does not use said macro and
> does not get #included in other source files.
> 
> If you remove the weird GLIBC check and the push/pop, you end up with the
> patch I had originally proposed:
> 
> #undef fstatat64

The question I can't get past is whether this is the correct way to solve this.  This just undoes musl's "#define fstatat64 fstatat" in sys/stat.h so that the 'fstatat64' token falls into the ALLOW_RULE template, leading to '__SNR_fstatat64' being used, and thus, no compile failure.  But why is musl clobbering fstatat64 to fstatat?  There are no comments in its source that provide any clues.

I kinda suspect the #define in sys/stat.h is just the headers piece of musl's fstatat* implementation.  In src/stat/fstatat.c, down at the very bottom, it defines an actual fstatat() function, then uses a weak_alias to tie fstatat64 --> fstatat.

#if !_REDIR_TIME64
weak_alias(fstatat, fstatat64);
#endif

I feel what we're trying to do is a kludge that just happens to work.  The real fix needs to be done upstream in one of the involved projects (musl, libssecomp, or file), but which one?  And the other factor is how much time do we want to spend trying trying to hash this out?

Comment 30 Mike Gilbert 2021-07-02 02:57:15 UTC

I suspect the #define in musl's sys/stat.h is meant as some kind of C-level compatibility shim so that fstatat64() calls get translated to musl's fstatat() syscall wrapper at compile time. It's a convenience for application programmers.

In the context of seccomp, we don't care what kind of C wrapper functions might exist: we want ALLOW_RULE(fstatat64) to get translated to some operation involving __NR_fstatat64, regardless of any C-library wrapper function that may or may not be defined.

It's really a tradeoff between convenience for app developers versus unexpected behavior for system programmers.

Given that we can't go back in time and prevent musl from shipping sys/stat.h with these weird syscall macros, I think this really needs to be worked around in the package that is defining/utilizing the ALLOW_RULE() macro.

Comment 31 Mike Gilbert 2021-07-02 03:11:24 UTC

Then again, I guess it would be fairly nonsensical for an application developer to call fstatat64() directly. So yeah, the macro definition in musl's header makes no sense without some further explanation.

I dropped this bug into #musl to see if there was any wisdom available, and dalias himself said that simply undefining the macro was an adequate fix. He said that he hoped to eradicate those macros in time, but the opportunity hadn't arisen yet.

"2021-06-23.log:[19:30:09] <dalias> veremitz, the #undef fstatat64 is perfectly fine. we want to get rid of those macros entirely"

Comment 33 Joshua Kinard 2021-07-02 22:17:50 UTC

(In reply to Michael 'veremitz' Everitt from comment #32)
> I dropped this bug into #musl to see if there was any wisdom available, and
> dalias himself said that simply undefining the macro was an adequate fix. He
> said that he hoped to eradicate those macros in time, but the opportunity
> hadn't arisen yet.
> 
> "2021-06-23.log:[19:30:09] <dalias> veremitz, the #undef fstatat64 is
> perfectly fine. we want to get rid of those macros entirely"

Okay, that sounds like the best path forward then.  Though, is that something we would send up to the maintainer of sys-apps/file?  E.g., is using #undef on those also acceptable for glibc and uclibc-ng systems since there's no sane way to make it conditional on musl?

Comment 34 Joshua Kinard 2021-07-18 06:09:39 UTC

Any chance we can get the #undef patch added to sys-apps/file in either the main repo, or pass it over to the musl team to carry in their repo until it is sent upstream?

Comment 35 Mike Gilbert 2021-07-18 17:25:13 UTC

Yeah, that sounds fine. I'll send something to file upstream this week as well.

Comment 36 Larry the Git Cow 2021-07-18 17:46:53 UTC

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2e20ec0fa649b0720f862615c6099b947848fd3c

commit 2e20ec0fa649b0720f862615c6099b947848fd3c
Author:     Mike Gilbert <floppym@gentoo.org>
AuthorDate: 2021-07-18 17:46:26 +0000
Commit:     Mike Gilbert <floppym@gentoo.org>
CommitDate: 2021-07-18 17:46:26 +0000

    sys-apps/file: fix seccomp build failure with musl
    
    Closes: https://bugs.gentoo.org/789336
    Signed-off-by: Mike Gilbert <floppym@gentoo.org>

 sys-apps/file/file-5.40-r3.ebuild                  |  1 +
 .../files/file-5.40-seccomp-fstatat64-musl.patch   | 31 ++++++++++++++++++++++
 2 files changed, 32 insertions(+)