Message ID | 20230413-nolibc-stdio-fix-v1-1-fa05fc3ba1fe@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1170777vqo; Thu, 13 Apr 2023 09:40:54 -0700 (PDT) X-Google-Smtp-Source: AKy350aH3es3vY5zA1Ky+535lfUzg+1/KaTW/NQxSeeq93T4Ow4Kd6hQAF81WzRp9Cx1HxS6/rE9 X-Received: by 2002:a05:6a20:c119:b0:db:c54a:bf53 with SMTP id bh25-20020a056a20c11900b000dbc54abf53mr2762696pzb.7.1681404054250; Thu, 13 Apr 2023 09:40:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681404054; cv=none; d=google.com; s=arc-20160816; b=HBwspyRhYDKYVid7d6wjvpYFuEOf5j8U7jIgj4HYToWT6p7L7a5MttmiMNz0lXNGFg vvR2pHmt/wy8ldS6dBXH/wR1Y4oAqcFN5EnMHBmOyj3lrBJzaUaKBb4Z9YUqYFT12Qwx LJ4ZQsWLHuzW2QB1abOFW8m16iGDRbshpOwFGZ68e7ptHRSLpUoDYxNepnoYjZhrIXl5 CzL1+SEynQm1IhOshwX/Wm/vsxl1uzMQNIDfYCM6axUHYXoe+bQORYVO4xYSIO15LeaM T6cuu1iG5zYdj9cDamnicqXqJOpH3GHzqGWtxhWZhJmJx1gqWT03NwGhIfRbsROVcQSg scMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=mv2PTMoY5NV46nKr+w1j5cBZ/f8PRqowWa8dAy/rX+A=; b=MaSaApkI+J+G9yToyQRuS/9JaTr+dwFfX1URX6APfbL2ZmJN+VswyN4b+FPEMv1UZI lrl8xwu2FoxnFvZ4lyWx+bo/OHncVbCP7Ezbf2ULv5ka0XTpNajNIJArMXF3i2N2pn8+ ngCdLxVzGZ7Xoi0PFEt5o6wMavUiV7ZU8HB7s+0wD+zVNRClD0fYfEkI7XT9fk1NhR/p tnLu10hT47ye/giFENNTfoTrE9QlFkrUCYymP++yGfDBkssoZOQeBEm3HAj0BhNLIv/N 8zHdGUSji+Y0XRr/rm4tqqAikuuvxiG4sswUd5Qpf2rX2kyaV3TDPE48ynPD3BtlyxSP 13GQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=faoA6LtQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v71-20020a63894a000000b0051b54dccffesi863612pgd.714.2023.04.13.09.40.39; Thu, 13 Apr 2023 09:40:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=faoA6LtQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229917AbjDMQ1D (ORCPT <rfc822;peter110.wang@gmail.com> + 99 others); Thu, 13 Apr 2023 12:27:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229598AbjDMQ1C (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 13 Apr 2023 12:27:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF9C89EC9; Thu, 13 Apr 2023 09:27:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 726A160C92; Thu, 13 Apr 2023 16:27:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64C6EC433EF; Thu, 13 Apr 2023 16:26:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681403219; bh=i7GBvPvooG+tmzW0Ins3MeH/7xGbUl62e/AeD/7Wy8M=; h=From:Date:Subject:To:Cc:From; b=faoA6LtQxa3jIalaOFgMr3e2UnmQ+8FXLnCVpK7QOP0gOGoIS4hEV/pAgrQY9MPZL Ytq04l74NhcKDDeowu3al8TY6oi9GQhQx26tDUeFyr8Te22b6ivCUDAURdFi3IeVdM Nvv8xLLrPhBXyGWdGbC1cILw3XguJzAnH6M5q9UpeQfEtlYqM4JnLpeRu1qf7Tn4Ax zee8MXOGg6GKbefU/zE00OWog/VJwclzSLDJP9Qc0LaP/lGu/3miTptUUHkL42VQ/A QDl6TIJQ41+/bMsfernHFUlPMgNSJ1pMOcGtHMmtjuVgwTY7X07LIm+nT0t4WYL+2n zAyimj+1e7axA== From: Mark Brown <broonie@kernel.org> Date: Thu, 13 Apr 2023 17:26:32 +0100 Subject: [PATCH] tools/nolibc: Fix build of stdio.h due to header ordering MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230413-nolibc-stdio-fix-v1-1-fa05fc3ba1fe@kernel.org> X-B4-Tracking: v=1; b=H4sIADctOGQC/x2NywqDMBBFf0Vm7UBM3KS/UlzkMepgScqM2IL47 41dnsM93BOUhEnh0Z0gdLByLQ2GvoO0hrIQcm4M1lhnxsFhqS+OCXXPXHHmL85xtJmcz8Z7aFk MShgllLTe4afKduu3UFv/n57Tdf0ADmykM3kAAAA= To: Willy Tarreau <w@1wt.eu>, "Paul E. McKenney" <paulmck@kernel.org>, =?utf-8?q?Thomas_Wei=C3=9Fschuh?= <linux@weissschuh.net> Cc: Shuah Khan <shuah@kernel.org>, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Mark Brown <broonie@kernel.org> X-Mailer: b4 0.13-dev-00303 X-Developer-Signature: v=1; a=openpgp-sha256; l=1225; i=broonie@kernel.org; h=from:subject:message-id; bh=i7GBvPvooG+tmzW0Ins3MeH/7xGbUl62e/AeD/7Wy8M=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBkOC1RARCbU+msmqb0fQxiZmjW+8hUcwDrICPJZOGk GBy2AUKJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZDgtUQAKCRAk1otyXVSH0EQiB/ 0WVVRlcV3AOi3rF1c+bUbo+NqWkqSAJswpAXeXAZQaNyN7zr35bCf8TPdSB+2QG6kvF24wVTxgIteP m9v2NOM/Z1B//AjhJSkUMJq3v5WOMp7zG8i/GNW3roDDe3DJhIm+7aRRG2Saw+rJOxHxBQ9wwD939+ 9CdFXzdPmfoT4k4+9v7MvHyZzprE2U3eS2WzWbUxNR2+4AgdzCEUbs4mhhwPhKkV5VjWx6+AoSYXEL 0ypqSU9FXmIuiaksj1pCXefGbnUZ037ooYEllEhIfNUNYX6ywnU9VpKnM1DbT/qPK1CBOqy/q6O9gE iTZ/MzuTbqLYIy4HXc1RADsnZl3Fjf X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763079937768437401?= X-GMAIL-MSGID: =?utf-8?q?1763079937768437401?= |
Series |
tools/nolibc: Fix build of stdio.h due to header ordering
|
|
Commit Message
Mark Brown
April 13, 2023, 4:26 p.m. UTC
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,
Comments
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 */