Open hakehuang opened 3 days ago
It's not really clear to me how commit a9a909c558c8c2069742aeee55aba831740826cd could affect anything to do with mbedtls or posix headers (so I think there was a misstep in the git bisect, likely missing a west update
), but this test does fail to build using the command below on main
, so I'll continue to debug.
twister -i -p mimxrt1170_evk/mimxrt1176/cm7 -s portability.posix.headers.newlib.with_posix_api
A bisect at my end identified 94d712e5cfe001996d7280c028e0e0303cf7b747 as the offending commit, which is also just as arbitrary and unrelated.
The search continues!
The bisect I ran points the same PR (https://github.com/zephyrproject-rtos/zephyr/pull/73978) however, the first commit of that PR does not break posix thing but fdtable.c
.
The error is:
.../zephyr/lib/os/fdtable.c: In function 'zvfs_rw':
.../zephyr/lib/os/fdtable.c:315:41: error: 'const struct fd_op_vtable' has no member named 'write_offset'; did you mean 'write_offs'?
315 | if (fdtable[fd].vtable->write_offset == NULL) {
| ^~~~~~~~~~~~
| write_offs
.../zephyr/lib/os/fdtable.c:319:51: error: 'const struct fd_op_vtable' has no member named 'write_offset'; did you mean 'write_offs'?
319 | res = fdtable[fd].vtable->write_offset(fdtable[fd].obj, buf, sz,
| ^~~~~~~~~~~~
| write_offs
.../zephyr/lib/os/fdtable.c:327:51: error: 'const struct fd_op_vtable' has no member named 'read_offset'; did you mean 'read_offs'?
327 | res = fdtable[fd].vtable->read_offset(fdtable[fd].obj, buf, sz,
| ^~~~~~~~~~~
| read_offs
.../zephyr/lib/os/fdtable.c:335:1: error: label 'unlock' defined but not used [-Werror=unused-label]
335 | unlock:
| ^~~~~~
the following commits in that PR do affect posix related implementation in various ways so my guess would be that it's more error compounding in what's been reported by @hakehuang
EDIT: this error gets fixed in a later commit in that same PR: https://github.com/cfriedt/zephyr/commit/88e631dc82a129853542c3dfbeadb995ac13714f#diff-c5e475ef95ce582f4a29b7c9669794a903686ea1d141f6095239e51176c99a5e
EDIT2: after fixing this error in the commit that introduced it, a new bisect points to https://github.com/zephyrproject-rtos/zephyr/pull/73978/commits/df00883bfb5682e5113675adb6390e1ff5d02a7a which also isn't directly related to the error reported here.
Not having all commits to build makes git bisect
a bit less useful to identify the offending commit.
I have the same problem. The sys/types.h from Newlib includes sys/select.h
(provided by Zephyr), when __BSD_VISIBLE
is set to 1. The sys/select.h
later includes zephyr/net/socket_select.h
which includes time.h
and zephyr/sys/fdtable.h
, which need off_t
, ssize_t
and clockid_t
.
Missing types should be provided by sys/types.h
, but sys/select.h
is included before these types are defined.
Including posix_features.h
using -imacro
doesn't solve the issue. We can't also rely on POSIX headers from Newlib, because some types have different representation (e.g. pthread_rwlockattr_t
).
For me, creating sys/types.h
with the following content worked (sys/types.h
from Newlib never includes sys/select.h
).
diff --git a/include/zephyr/posix/sys/types.h b/include/zephyr/posix/sys/types.h
new file mode 100644
index 00000000000..9a13cfbda64
--- /dev/null
+++ b/include/zephyr/posix/sys/types.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (c) 2024 Google LLC
+ *
+ * SPDX-License-Identifier: Apache-2.0
+ */
+
+#ifndef ZEPHYR_INCLUDE_POSIX_SYS_TYPES_H_
+#define ZEPHYR_INCLUDE_POSIX_SYS_TYPES_H_
+
+#ifdef CONFIG_NEWLIB_LIBC
+
+#include <sys/features.h>
+#undef __BSD_VISIBLE
+
+#endif /* CONFIG_NEWLIB_LIBC */
+
+#include_next <sys/types.h>
+
+#endif /* ZEPHYR_INCLUDE_POSIX_SYS_TYPES_H_ */
Just got back (I have quite a commute :-/). Looking at it again.
I think part of the issue is that posix types are being used where they probably shouldn't be.
off_t
, ssize_t
and <sys/types.h>
are all part of posix but are being used in fdtable.h (below the posix api). The problem is compounded because all of the fdtable.h consumers are also therefore forced to use posix types creating a bit of a layering rat's nest.
I have a fairly simple workaround (just define the types locally). They should be removed (after v3.7.0)
Very strange how this somehow managed to go through CI without triggering any failures on the original set of PRs...
Describe the bug
build failure in the following platforms:
To Reproduce Steps to reproduce the behavior:
Expected behavior build PASS
Impact POSIX compatible ~190 failures in weekly CI Failures in PRs CI when these tests are triggered
Logs and console output
Environment (please complete the following information):
Additional info Introduced by #73978 PR is not bisectable
Edited by @aescolar to encompass all cases of the same issue