When we added fd based file streams we created references to STx_FILENO in
stdio.h but these constants are declared in unistd.h which is the last file
included by the top level nolibc.h meaning those constants are not defined
when we try to build stdio.h. This causes programs using nolibc.h to fail
to build.
Reorder the headers to avoid this issue.
Fixes: d449546c957f ("tools/nolibc: implement fd-based FILE streams")
Signed-off-by: Mark Brown <[email protected]>
---
tools/include/nolibc/nolibc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/include/nolibc/nolibc.h b/tools/include/nolibc/nolibc.h
index 04739a6293c4..05a228a6ee78 100644
--- a/tools/include/nolibc/nolibc.h
+++ b/tools/include/nolibc/nolibc.h
@@ -99,11 +99,11 @@
#include "sys.h"
#include "ctype.h"
#include "signal.h"
+#include "unistd.h"
#include "stdio.h"
#include "stdlib.h"
#include "string.h"
#include "time.h"
-#include "unistd.h"
#include "stackprotector.h"
/* Used by programs to avoid std includes */
---
base-commit: 7d8214bba44c1aa6a75921a09a691945d26a8d43
change-id: 20230413-nolibc-stdio-fix-fb42de39d099
Best regards,
--
Mark Brown <[email protected]>
Hi Mark,
Sorry for this issue, I don't know why it didn't trigger in our tests,
maybe due to the includes being explicit in the test program.
On Thu, Apr 13, 2023 at 05:26:32PM +0100, Mark Brown wrote:
> When we added fd based file streams we created references to STx_FILENO in
> stdio.h but these constants are declared in unistd.h which is the last file
> included by the top level nolibc.h meaning those constants are not defined
> when we try to build stdio.h. This causes programs using nolibc.h to fail
> to build.
>
> Reorder the headers to avoid this issue.
>
> Fixes: d449546c957f ("tools/nolibc: implement fd-based FILE streams")
> Signed-off-by: Mark Brown <[email protected]>
Acked-by: Willy Tarreau <[email protected]>
Paul, the commit above is in your rcu/next branch but fortunately not
in the series you've prepared for 6.4, so it will be sufficient to pick
it on top of next and you can take it directly if you want.
Thanks!
Willy
On Thu, Apr 13, 2023 at 07:08:59PM +0200, Willy Tarreau wrote:
> Hi Mark,
>
> Sorry for this issue, I don't know why it didn't trigger in our tests,
> maybe due to the includes being explicit in the test program.
>
> On Thu, Apr 13, 2023 at 05:26:32PM +0100, Mark Brown wrote:
> > When we added fd based file streams we created references to STx_FILENO in
> > stdio.h but these constants are declared in unistd.h which is the last file
> > included by the top level nolibc.h meaning those constants are not defined
> > when we try to build stdio.h. This causes programs using nolibc.h to fail
> > to build.
> >
> > Reorder the headers to avoid this issue.
> >
> > Fixes: d449546c957f ("tools/nolibc: implement fd-based FILE streams")
> > Signed-off-by: Mark Brown <[email protected]>
> Acked-by: Willy Tarreau <[email protected]>
>
> Paul, the commit above is in your rcu/next branch but fortunately not
> in the series you've prepared for 6.4, so it will be sufficient to pick
> it on top of next and you can take it directly if you want.
Queued and pushed, thank you both!
With respect to -next, travel plans next week are causing me to instead
update my rcu/next branch to the merge point of all of this coming
merge window's pull requests. Though it only makes a difference of a
few days, as I would normally pull rcu/next back the Monday before the
merge window opens.
There is some possibility that I will be off the grid for extended periods
next week, which shouldn't make any difference for nolibc, aside from my
possibly being unresponsive during that time. The odds of an emergency
fix to last merge window's changes are quite low this late in cycle,
and I will be back before the next merge window opens.
Just let me know what I need to pull in, and I will do that early the
week after this coming one. Or you can buffer it up and send me one
big series upon my return, your choice. Either way works for me. ;-)
Thanx, Paul
Hi Paul,
On Thu, Apr 13, 2023 at 10:33:54AM -0700, Paul E. McKenney wrote:
> Queued and pushed, thank you both!
Thanks!
> With respect to -next, travel plans next week are causing me to instead
> update my rcu/next branch to the merge point of all of this coming
> merge window's pull requests. Though it only makes a difference of a
> few days, as I would normally pull rcu/next back the Monday before the
> merge window opens.
>
> There is some possibility that I will be off the grid for extended periods
> next week, which shouldn't make any difference for nolibc, aside from my
> possibly being unresponsive during that time. The odds of an emergency
> fix to last merge window's changes are quite low this late in cycle,
> and I will be back before the next merge window opens.
>
> Just let me know what I need to pull in, and I will do that early the
> week after this coming one. Or you can buffer it up and send me one
> big series upon my return, your choice. Either way works for me. ;-)
Thanks for letting us know! Anyway there shouldn't be anything urgent
with nolibc. And if anyone would be blocked I would go back to the old
method where I queue that in a branch in my repo, so please travel in
peace ;-)
Thank you!
Willy
On Thu, Apr 13, 2023 at 07:42:34PM +0200, Willy Tarreau wrote:
> Hi Paul,
>
> On Thu, Apr 13, 2023 at 10:33:54AM -0700, Paul E. McKenney wrote:
> > Queued and pushed, thank you both!
>
> Thanks!
>
> > With respect to -next, travel plans next week are causing me to instead
> > update my rcu/next branch to the merge point of all of this coming
> > merge window's pull requests. Though it only makes a difference of a
> > few days, as I would normally pull rcu/next back the Monday before the
> > merge window opens.
> >
> > There is some possibility that I will be off the grid for extended periods
> > next week, which shouldn't make any difference for nolibc, aside from my
> > possibly being unresponsive during that time. The odds of an emergency
> > fix to last merge window's changes are quite low this late in cycle,
> > and I will be back before the next merge window opens.
> >
> > Just let me know what I need to pull in, and I will do that early the
> > week after this coming one. Or you can buffer it up and send me one
> > big series upon my return, your choice. Either way works for me. ;-)
>
> Thanks for letting us know! Anyway there shouldn't be anything urgent
> with nolibc. And if anyone would be blocked I would go back to the old
> method where I queue that in a branch in my repo, so please travel in
> peace ;-)
Thank you, Willy!
Thanx, Paul