| Message ID | 20230413-nolibc-stdio-fix-v1-1-fa05fc3ba1fe@kernel.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | d7eafa64a158cc9f1d26b3c615d4ada3c17c02ee |
| Headers | show |
| Series | tools/nolibc: Fix build of stdio.h due to header ordering | expand |
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 <broonie@kernel.org> Acked-by: Willy Tarreau <w@1wt.eu> 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 <broonie@kernel.org> > Acked-by: Willy Tarreau <w@1wt.eu> > > 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
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 */
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 <broonie@kernel.org> --- tools/include/nolibc/nolibc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- base-commit: 7d8214bba44c1aa6a75921a09a691945d26a8d43 change-id: 20230413-nolibc-stdio-fix-fb42de39d099 Best regards,