glibc-2.27 memfd_create not being detected correctly with kernels 3.10.y/3.14.y #8099
Comments
|
If I understand correctly, Note that, in the case of Fedora, v27 (the most recent release) does not have |
|
Yes, I believe 85db59b should have addressed this issue and should now be configuring In short, it would appear that |
|
We don't have glibc-2.27 in Fedora. The latest is glibc-devel-2.26.9000-51.fc28.x86_64. I expect that it's essentially identical to the released version though. I tried to replicate the build failure with glibc-2.26.9000, and kernels going back to kernel-headers-4.9.4-201.fc25.x86_64, and it builds fine. But I'm on amd64, arm might be different. Please attach |
|
Builds fine on Fedora arm too: kernel-headers-4.14.13-300.fc27.armv7hl and glibc-devel-2.26.9000-51.fc28.armv7hl. |
|
There is no problem with glibc-2.26 - I can build systemd-237 with glibc-2.26 and (for example) kernel 3.10.108 without any issue, as glibc-2.26 does not implement However, when building with glibc-2.27 and systemd-237 and 3.10.108 (or 3.14.29), systemd will fail to build as systemd fails to determine the presence of This only seems to be an issue with kernels that DON'T implement meson-log.txt (systemd-237 + glibc-2.27 + kernel 3.14.29): http://ix.io/FhH (which fails) With 3.14.29, the first test fails as The next test also fails (but shouldn't!) because Is the |
|
Oh, I think it comes down to the meson version. With meson-0.44.0: Essentially, the test is broken in meson-0.42. |
|
Ah OK thanks, I'll try upgrading to meson-0.44.0 and will report back once I've tested. |
|
Unfortunately I'm not seeing any difference with meson-0.44.0: http://ix.io/Fik Note that it's not the first test that is the problem, it's the second: The failure of this second test leaves |
|
Oh, OK. So the test fails because But on Fedora, even with kernel-headers-3.16.3-302.fc21.x86_64, |
|
By the way I'm building with gcc-7.3.0. I don't know what else to look for, but I have a workaround for now. If not reproducible, then no big deal. |
|
It's probably reproducible, but requires the right combination of kernel/glibc... |
|
I now tested with glibc-devel-2.27-1.fc28.x86_64, and it works. |
|
Did I mention I'm cross-compiling? :) |
|
To recap: the build is failing because either The real issue is that there's confusion in what
So either our logic or meson needs to change. |
In meson.build we check that functions are available using:
meson.get_compiler('c').has_function('foo')
which checks the following:
if __stub_foo or __stub___foo are defined, return false
if foo is declared (a pointer to the function can be taken), return true
otherwise check for __builtin_memfd_create
_stub is documented by glibc as
It defines a symbol '__stub_FUNCTION' for each function
in the C library which is a stub, meaning it will fail
every time called, usually setting errno to ENOSYS.
So if __stub is defined, we know we don't want to use the glibc version, but
this doesn't tell us if the name itself is defined or not. If it _is_ defined,
and we define our replacement as an inline static function, we get an error:
In file included from ../src/basic/missing.h:1358:0,
from ../src/basic/util.h:47,
from ../src/basic/calendarspec.h:29,
from ../src/basic/calendarspec.c:34:
../src/basic/missing_syscall.h:65:19: error: static declaration of 'memfd_create' follows non-static declaration
static inline int memfd_create(const char *name, unsigned int flags) {
^~~~~~~~~~~~
.../usr/include/bits/mman-shared.h:46:5: note: previous declaration of 'memfd_create' was here
int memfd_create (const char *__name, unsigned int __flags) __THROW;
^~~~~~~~~~~~
To avoid this problem, call our inline functions different than glibc,
and use a #define to map the official name to our replacement.
Fixes systemd#8099.
In meson.build we check that functions are available using:
meson.get_compiler('c').has_function('foo')
which checks the following:
- if __stub_foo or __stub___foo are defined, return false
- if foo is declared (a pointer to the function can be taken), return true
- otherwise check for __builtin_memfd_create
_stub is documented by glibc as
It defines a symbol '__stub_FUNCTION' for each function
in the C library which is a stub, meaning it will fail
every time called, usually setting errno to ENOSYS.
So if __stub is defined, we know we don't want to use the glibc version, but
this doesn't tell us if the name itself is defined or not. If it _is_ defined,
and we define our replacement as an inline static function, we get an error:
In file included from ../src/basic/missing.h:1358:0,
from ../src/basic/util.h:47,
from ../src/basic/calendarspec.h:29,
from ../src/basic/calendarspec.c:34:
../src/basic/missing_syscall.h:65:19: error: static declaration of 'memfd_create' follows non-static declaration
static inline int memfd_create(const char *name, unsigned int flags) {
^~~~~~~~~~~~
.../usr/include/bits/mman-shared.h:46:5: note: previous declaration of 'memfd_create' was here
int memfd_create (const char *__name, unsigned int __flags) __THROW;
^~~~~~~~~~~~
To avoid this problem, call our inline functions different than glibc,
and use a #define to map the official name to our replacement.
Fixes systemd#8099.
v2:
- use "missing_" as the prefix instead of "_"
In meson.build we check that functions are available using:
meson.get_compiler('c').has_function('foo')
which checks the following:
- if __stub_foo or __stub___foo are defined, return false
- if foo is declared (a pointer to the function can be taken), return true
- otherwise check for __builtin_memfd_create
_stub is documented by glibc as
It defines a symbol '__stub_FUNCTION' for each function
in the C library which is a stub, meaning it will fail
every time called, usually setting errno to ENOSYS.
So if __stub is defined, we know we don't want to use the glibc version, but
this doesn't tell us if the name itself is defined or not. If it _is_ defined,
and we define our replacement as an inline static function, we get an error:
In file included from ../src/basic/missing.h:1358:0,
from ../src/basic/util.h:47,
from ../src/basic/calendarspec.h:29,
from ../src/basic/calendarspec.c:34:
../src/basic/missing_syscall.h:65:19: error: static declaration of 'memfd_create' follows non-static declaration
static inline int memfd_create(const char *name, unsigned int flags) {
^~~~~~~~~~~~
.../usr/include/bits/mman-shared.h:46:5: note: previous declaration of 'memfd_create' was here
int memfd_create (const char *__name, unsigned int __flags) __THROW;
^~~~~~~~~~~~
To avoid this problem, call our inline functions different than glibc,
and use a #define to map the official name to our replacement.
Fixes systemd#8099.
v2:
- use "missing_" as the prefix instead of "_"
v3:
- rebase and update for statx()
Unfortunately "statx" is also present in "struct statx", so the define
causes issues. Work around this by using a typedef.
I checked that systemd compiles with current glibc
(glibc-devel-2.26-24.fc27.x86_64) if HAVE_MEMFD_CREATE, HAVE_GETTID,
HAVE_PIVOT_ROOT, HAVE_SETNS, HAVE_RENAMEAT2, HAVE_KCMP, HAVE_KEYCTL,
HAVE_COPY_FILE_RANGE, HAVE_BPF, HAVE_STATX are forced to 0.
Setting HAVE_NAME_TO_HANDLE_AT to 0 causes an issue, but it's not because of
the define, but because of struct file_handle.
#8229) In meson.build we check that functions are available using: meson.get_compiler('c').has_function('foo') which checks the following: - if __stub_foo or __stub___foo are defined, return false - if foo is declared (a pointer to the function can be taken), return true - otherwise check for __builtin_memfd_create _stub is documented by glibc as It defines a symbol '__stub_FUNCTION' for each function in the C library which is a stub, meaning it will fail every time called, usually setting errno to ENOSYS. So if __stub is defined, we know we don't want to use the glibc version, but this doesn't tell us if the name itself is defined or not. If it _is_ defined, and we define our replacement as an inline static function, we get an error: In file included from ../src/basic/missing.h:1358:0, from ../src/basic/util.h:47, from ../src/basic/calendarspec.h:29, from ../src/basic/calendarspec.c:34: ../src/basic/missing_syscall.h:65:19: error: static declaration of 'memfd_create' follows non-static declaration static inline int memfd_create(const char *name, unsigned int flags) { ^~~~~~~~~~~~ .../usr/include/bits/mman-shared.h:46:5: note: previous declaration of 'memfd_create' was here int memfd_create (const char *__name, unsigned int __flags) __THROW; ^~~~~~~~~~~~ To avoid this problem, call our inline functions different than glibc, and use a #define to map the official name to our replacement. Fixes #8099. v2: - use "missing_" as the prefix instead of "_" v3: - rebase and update for statx() Unfortunately "statx" is also present in "struct statx", so the define causes issues. Work around this by using a typedef. I checked that systemd compiles with current glibc (glibc-devel-2.26-24.fc27.x86_64) if HAVE_MEMFD_CREATE, HAVE_GETTID, HAVE_PIVOT_ROOT, HAVE_SETNS, HAVE_RENAMEAT2, HAVE_KCMP, HAVE_KEYCTL, HAVE_COPY_FILE_RANGE, HAVE_BPF, HAVE_STATX are forced to 0. Setting HAVE_NAME_TO_HANDLE_AT to 0 causes an issue, but it's not because of the define, but because of struct file_handle.
|
I am on systemd 238 and have the same issue while making pulseaudio-raop2. |
That's a problem you should report to the developers of "pulseaudio-raop2". It has nothing to do with systemd. |
|
@floppym Really? Becasue it makes fine with systemd 234, Ubuntu Zesty, so I suspect some thing wrong in systemd 238? |
|
Ubuntu Zesty probably has an older version of glibc. |
|
@floppym I think it glibc 2.24-9ubuntu2.2 |
|
glibc-2.24 is obviously older than glibc-2.27, which is the version which triggered the bug reported in this systemd bug report. Again, your pulseaudio-raop2 build failure has nothing to do with systemd, despite what your Google search may be returning. |
|
Ok Thanks! |
|
It will probably work if you remove the function definition from https://github.com/hfujita/pulseaudio-raop2/blob/hf/raop2-v7-next/src/pulsecore/memfd-wrappers.h#L36. |
|
@floppym Thank you! Although it is late, I will try your suggestion, tomorrow morning after the system finish upgrading with glibc 2.7.2 |
|
Your suggestion work, however it not makes it due to openssl 1.1.0 API backward incompatibility. |
Backport a fix that is needed for systemd to build with latest glibc and kernel being old. see systemd/systemd#8099 Signed-off-by: Khem Raj <raj.khem@gmail.com>
Backport a fix that is needed for systemd to build with latest glibc and kernel being old. see systemd/systemd#8099 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Backport a fix that is needed for systemd to build with latest glibc and kernel being old. see systemd/systemd#8099 (From OE-Core rev: 169d061b313ebb91bf18f09d998a42c4ae165bf8) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport of https://patchwork.openembedded.org/patch/149455/ which is a backport of systemd@5187dd2 + port of https://patchwork.openembedded.org/patch/141490/ Upstream-Status: Backport [systemd#8099]
Backport a fix that is needed for systemd to build with latest glibc and kernel being old. see systemd/systemd#8099 (From OE-Core rev: 169d061) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Submission type
systemd version the issue has been seen with
Used distribution
In case of bug report: Expected behaviour you didn't see
In case of bug report: Unexpected behaviour you saw
In case of bug report: Steps to reproduce the problem
I've encountered a problem building systemd-237 and glibc-2.27 with kernels that do not implement the
memfd_createsyscall (ie. any kernel before 3.17.0).For example, when building 3.10.108, glibc-2.27 and systemd-237:
The
HAVE_MEMFD_CREATEdetection inmeson.buildis failing to determine thatmemfd_createis now implemented by glibc-2.27, however it appears to fail only when the kernel does not also implement this syscall. If the kernel does implementmemfd_create, ie. 4.14.16, then the meson detection works as expected and the build succeeds.system-237 sets the following
#defines when building with glibc-2.27 and the stated kernels:kernel 3.10.108:
kernel 3.14.29:
kernel 4.14.16:
Consequently systemd-237 fails to build with glibc-2.27 and kernels 3.10.108 and 3.14.29 (see build error, above), but builds successfully with 4.14.16.
Since LibreELEC will only be building with
glibc-2.27(which implementsmemfd_create) as a workaround I'm using this patch to force enableHAVE_MEMFD_CREATEinmeson.buildand I'm able to successfully build systemd-237 with all kernels.The patch confirms that systemd-237 is building with the glibc-2.27 implementation of
memfd_createbecause if we use the patch and build systemd-237 with glibc-2.26 (and not glibc-2.27) then systemd will fail to build asmemfd_createis no longer declared. For example:However this patch, while it works, is not ideal as we'd rather not patch against upstream. And it's just a hack.
Does anyone have any idea why
HAVE_MEMFD_CREATEis not being determined correctly bymeson.buildwhen the kernel does not implementmemfd_createbutglibcdoes?The text was updated successfully, but these errors were encountered: