From: Arnd Bergmann <[email protected]>
As we change the C language standard for the kernel from gnu89 to
gnu11, it makes sense to also update the version for user space
compilation.
Some users have older native compilers than what they use for
kernel builds, so I considered using gnu99 as the default version
for wider compatibility with gcc-4.6 and earlier.
However, testing with older compilers showed that we already require
HOSTCC version 5.1 as well because a lot of host tools include
linux/compiler.h that uses __has_attribute():
CC tools/objtool/exec-cmd.o
In file included from tools/include/linux/compiler_types.h:36:0,
from tools/include/linux/compiler.h:5,
from exec-cmd.c:2:
tools/include/linux/compiler-gcc.h:19:5: error: "__has_attribute" is not defined [-Werror=undef]
Signed-off-by: Arnd Bergmann <[email protected]>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 37ef6a555dcd..7c9be7f1ccd4 100644
--- a/Makefile
+++ b/Makefile
@@ -432,7 +432,7 @@ HOSTCXX = g++
endif
export KBUILD_USERCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
- -O2 -fomit-frame-pointer -std=gnu89 \
+ -O2 -fomit-frame-pointer -std=gnu11 \
-Wdeclaration-after-statement
export KBUILD_USERLDFLAGS :=
--
2.29.2
On Tue, Mar 1, 2022 at 6:52 AM Arnd Bergmann <[email protected]> wrote:
>
> From: Arnd Bergmann <[email protected]>
>
> As we change the C language standard for the kernel from gnu89 to
> gnu11, it makes sense to also update the version for user space
> compilation.
>
> Some users have older native compilers than what they use for
> kernel builds, so I considered using gnu99 as the default version
> for wider compatibility with gcc-4.6 and earlier.
>
> However, testing with older compilers showed that we already require
> HOSTCC version 5.1 as well because a lot of host tools include
> linux/compiler.h that uses __has_attribute():
>
> CC tools/objtool/exec-cmd.o
> In file included from tools/include/linux/compiler_types.h:36:0,
> from tools/include/linux/compiler.h:5,
> from exec-cmd.c:2:
> tools/include/linux/compiler-gcc.h:19:5: error: "__has_attribute" is not defined [-Werror=undef]
>
> Signed-off-by: Arnd Bergmann <[email protected]>
Thanks for the patches!
Reviewed-by: Nick Desaulniers <[email protected]>
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 37ef6a555dcd..7c9be7f1ccd4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -432,7 +432,7 @@ HOSTCXX = g++
> endif
>
> export KBUILD_USERCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
> - -O2 -fomit-frame-pointer -std=gnu89 \
> + -O2 -fomit-frame-pointer -std=gnu11 \
> -Wdeclaration-after-statement
> export KBUILD_USERLDFLAGS :=
>
> --
> 2.29.2
>
--
Thanks,
~Nick Desaulniers
On Tue, Mar 01, 2022 at 03:52:33PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <[email protected]>
>
> As we change the C language standard for the kernel from gnu89 to
> gnu11, it makes sense to also update the version for user space
> compilation.
>
> Some users have older native compilers than what they use for
> kernel builds, so I considered using gnu99 as the default version
> for wider compatibility with gcc-4.6 and earlier.
>
> However, testing with older compilers showed that we already require
> HOSTCC version 5.1 as well because a lot of host tools include
> linux/compiler.h that uses __has_attribute():
>
> CC tools/objtool/exec-cmd.o
> In file included from tools/include/linux/compiler_types.h:36:0,
> from tools/include/linux/compiler.h:5,
> from exec-cmd.c:2:
> tools/include/linux/compiler-gcc.h:19:5: error: "__has_attribute" is not defined [-Werror=undef]
For what it's worth, I think this is a bug:
https://lore.kernel.org/r/[email protected]/
https://lore.kernel.org/r/[email protected]/
I never got clear feedback on resolving it from the first thread and
nobody bothered to pick up the second patch.
> Signed-off-by: Arnd Bergmann <[email protected]>
Nobody has yelled that loud though, so this is probably fine.
Reviewed-by: Nathan Chancellor <[email protected]>
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 37ef6a555dcd..7c9be7f1ccd4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -432,7 +432,7 @@ HOSTCXX = g++
> endif
>
> export KBUILD_USERCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
> - -O2 -fomit-frame-pointer -std=gnu89 \
> + -O2 -fomit-frame-pointer -std=gnu11 \
> -Wdeclaration-after-statement
> export KBUILD_USERLDFLAGS :=
>
> --
> 2.29.2
>
>
On Wed, Mar 2, 2022 at 10:47 AM Arnd Bergmann <[email protected]> wrote:
>
> From: Arnd Bergmann <[email protected]>
>
> As we change the C language standard for the kernel from gnu89 to
> gnu11, it makes sense to also update the version for user space
> compilation.
>
Overdue.
Can you point me to a lore link where I can easily fetch the full 3/3
v3 patchset?
I would like to give this a try on x86-64 with my latest kernel-config
(based on the latest kernel-config v5.17-rc5 from Debian/unstable).
What Linux source base do I need?
Is Linux v5.17-rc6 good enough (patchset applicable) for testing?
Thanks, Arnd.
Regards,
- Sedat -
> Some users have older native compilers than what they use for
> kernel builds, so I considered using gnu99 as the default version
> for wider compatibility with gcc-4.6 and earlier.
>
> However, testing with older compilers showed that we already require
> HOSTCC version 5.1 as well because a lot of host tools include
> linux/compiler.h that uses __has_attribute():
>
> CC tools/objtool/exec-cmd.o
> In file included from tools/include/linux/compiler_types.h:36:0,
> from tools/include/linux/compiler.h:5,
> from exec-cmd.c:2:
> tools/include/linux/compiler-gcc.h:19:5: error: "__has_attribute" is not defined [-Werror=undef]
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 37ef6a555dcd..7c9be7f1ccd4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -432,7 +432,7 @@ HOSTCXX = g++
> endif
>
> export KBUILD_USERCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
> - -O2 -fomit-frame-pointer -std=gnu89 \
> + -O2 -fomit-frame-pointer -std=gnu11 \
> -Wdeclaration-after-statement
> export KBUILD_USERLDFLAGS :=
>
> --
> 2.29.2
>
On Wed, Mar 2, 2022 at 2:14 PM Sedat Dilek <[email protected]> wrote:
>
> On Wed, Mar 2, 2022 at 10:47 AM Arnd Bergmann <[email protected]> wrote:
> >
> > From: Arnd Bergmann <[email protected]>
> >
> > As we change the C language standard for the kernel from gnu89 to
> > gnu11, it makes sense to also update the version for user space
> > compilation.
> >
>
> Overdue.
>
> Can you point me to a lore link where I can easily fetch the full 3/3
> v3 patchset?
Hey Sedat!
$ b4 am https://lore.kernel.org/lkml/[email protected]/
-o - | git am -3
https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation
>
> I would like to give this a try on x86-64 with my latest kernel-config
> (based on the latest kernel-config v5.17-rc5 from Debian/unstable).
>
> What Linux source base do I need?
> Is Linux v5.17-rc6 good enough (patchset applicable) for testing?
I suspect so.
--
Thanks,
~Nick Desaulniers
On Wed, Mar 2, 2022 at 11:54 PM Nick Desaulniers
<[email protected]> wrote:
>
> On Wed, Mar 2, 2022 at 2:14 PM Sedat Dilek <[email protected]> wrote:
> >
> > On Wed, Mar 2, 2022 at 10:47 AM Arnd Bergmann <[email protected]> wrote:
> > >
> > > From: Arnd Bergmann <[email protected]>
> > >
> > > As we change the C language standard for the kernel from gnu89 to
> > > gnu11, it makes sense to also update the version for user space
> > > compilation.
> > >
> >
> > Overdue.
> >
> > Can you point me to a lore link where I can easily fetch the full 3/3
> > v3 patchset?
>
> Hey Sedat!
>
> $ b4 am https://lore.kernel.org/lkml/[email protected]/
> -o - | git am -3
>
Hey Nick!
This only applies 1/3.
$ b4 --version
0.8.0
$ b4 am https://lore.kernel.org/lkml/[email protected]/
-o - | git am -3
Analyzing 14 messages in the thread
Will use the latest revision: v3
You can pick other revisions using the -vN flag
Checking attestation on all messages, may take a moment...
---
✓ [PATCH v3 1/3] Kbuild: move to -std=gnu11
✓ Signed: DKIM/kernel.org
+ Reviewed-by: Nathan Chancellor <[email protected]> (✓ DKIM/kernel.org)
ERROR: missing [2/3]!
ERROR: missing [3/3]!
---
NOTE: install patatt for end-to-end signature verification
---
Total patches: 1
---
WARNING: Thread incomplete!
Link: https://lore.kernel.org/r/[email protected]
Base: not specified
Wende an: Kbuild: move to -std=gnu11
- Sedat -
> https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation
>
> >
> > I would like to give this a try on x86-64 with my latest kernel-config
> > (based on the latest kernel-config v5.17-rc5 from Debian/unstable).
> >
> > What Linux source base do I need?
> > Is Linux v5.17-rc6 good enough (patchset applicable) for testing?
>
> I suspect so.
> --
> Thanks,
> ~Nick Desaulniers
Hi Sedat,
On Thu, Mar 03, 2022 at 07:26:05AM +0100, Sedat Dilek wrote:
> Hey Nick!
>
> This only applies 1/3.
>
> $ b4 --version
> 0.8.0
>
> $ b4 am https://lore.kernel.org/lkml/[email protected]/
> -o - | git am -3
> Analyzing 14 messages in the thread
> Will use the latest revision: v3
> You can pick other revisions using the -vN flag
> Checking attestation on all messages, may take a moment...
> ---
> ✓ [PATCH v3 1/3] Kbuild: move to -std=gnu11
> ✓ Signed: DKIM/kernel.org
> + Reviewed-by: Nathan Chancellor <[email protected]> (✓ DKIM/kernel.org)
> ERROR: missing [2/3]!
> ERROR: missing [3/3]!
> ---
> NOTE: install patatt for end-to-end signature verification
> ---
> Total patches: 1
> ---
> WARNING: Thread incomplete!
> Link: https://lore.kernel.org/r/[email protected]
> Base: not specified
> Wende an: Kbuild: move to -std=gnu11
It looks like the threading somehow got broken, likely due to the [v3]
on the first patch and not the second or third:
This worked for me on v5.17-rc6:
$ for i in $(seq 1 3); do b4 shazam -P _ 20220301145233.3689119-"$i"[email protected]; done
"b4 shazam" is the equivalent of "b4 am -o - ... | git am" and the
"-P _" tells b4 to only fetch that exact message ID, not the whole
thread.
Cheers,
Nathan
On Thu, Mar 3, 2022 at 6:37 PM Nathan Chancellor <[email protected]> wrote:
>
> Hi Sedat,
>
> On Thu, Mar 03, 2022 at 07:26:05AM +0100, Sedat Dilek wrote:
> > Hey Nick!
> >
> > This only applies 1/3.
> >
> > $ b4 --version
> > 0.8.0
> >
> > $ b4 am https://lore.kernel.org/lkml/[email protected]/
> > -o - | git am -3
> > Analyzing 14 messages in the thread
> > Will use the latest revision: v3
> > You can pick other revisions using the -vN flag
> > Checking attestation on all messages, may take a moment...
> > ---
> > ✓ [PATCH v3 1/3] Kbuild: move to -std=gnu11
> > ✓ Signed: DKIM/kernel.org
> > + Reviewed-by: Nathan Chancellor <[email protected]> (✓ DKIM/kernel.org)
> > ERROR: missing [2/3]!
> > ERROR: missing [3/3]!
> > ---
> > NOTE: install patatt for end-to-end signature verification
> > ---
> > Total patches: 1
> > ---
> > WARNING: Thread incomplete!
> > Link: https://lore.kernel.org/r/[email protected]
> > Base: not specified
> > Wende an: Kbuild: move to -std=gnu11
>
> It looks like the threading somehow got broken, likely due to the [v3]
> on the first patch and not the second or third:
>
> This worked for me on v5.17-rc6:
>
> $ for i in $(seq 1 3); do b4 shazam -P _ 20220301145233.3689119-"$i"[email protected]; done
>
> "b4 shazam" is the equivalent of "b4 am -o - ... | git am" and the
> "-P _" tells b4 to only fetch that exact message ID, not the whole
> thread.
>
Hmm, the universe is not good to me...
$ for i in $(seq 1 3); do b4 shazam -P _
20220301145233.3689119-"$i"[email protected]; done
usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
b4: error: argument subcmd: invalid choice: 'shazam' (choose from
'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
b4: error: argument subcmd: invalid choice: 'shazam' (choose from
'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
b4: error: argument subcmd: invalid choice: 'shazam' (choose from
'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
Do I need a higher version of b4 (here: v0.8.0)?
Check myself... b4.git:
commit 7c1d044ff1d5235e598d4c777c4abfe60e0a09a8
("shazam: change default behaviour to be "apply-here"")
...is post-v0.8.0.
Lemme see if I can apply this patch...
# cd /usr/lib/python3/dist-packages
# LC_ALL=C git apply --check --verbose /root/b4-shazam.patch
Checking patch b4/command.py...
error: while searching for:
sp.add_argument('-M', '--save-as-maildir', dest='maildir',
action='store_true', default=False,
help='Save as maildir (avoids mbox format ambiguities)')
def cmd_am_common_opts(sp):
sp.add_argument('-v', '--use-version', dest='wantver', type=int,
default=None,
help='Get a specific version of the patch/series')
error: patch failed: b4/command.py:35
error: b4/command.py: patch does not apply
Checking patch b4/mbox.py...
error: while searching for:
ifh = io.StringIO()
b4.save_git_am_mbox(am_msgs, ifh)
ambytes = ifh.getvalue().encode()
if cmdargs.applyhere:
amflags = config.get('git-am-flags', '')
sp = shlex.shlex(amflags, posix=True)
sp.whitespace_split = True
error: patch failed: b4/mbox.py:262
error: b4/mbox.py: patch does not apply
Nope.
Dunno if I am willing to do that manually or build-from-git.
Anyway, can you add this b4 shazam tipp/trick to our wiki, please?
Last question:
LLVM/Clang-14...
Do I need any patches to Linux v5.17-rc6 or upstream Git?
Dependent/Independent of "std-gnu-11"?
I can see on my Debian/unstable AMD64 system:
# LC_ALL=C apt-cache policy clang-14
clang-14:
Installed: (none)
Candidate: 1:14.0.0~++20220301114802+19149538e9a9-1~exp1~20220301234814.85
Version table:
1:14.0.0~++20220301114802+19149538e9a9-1~exp1~20220301234814.85 99
99 https://apt.llvm.org/unstable llvm-toolchain-14/main amd64 Packages
1:14.0.0~+rc1-1 99
99 https://ftp.debian.org/debian unstable/main amd64 Packages
99 https://deb.debian.org/debian unstable/main amd64 Packages
The one from apt.llvm.org I guess is LLVM/Clang v14.0.0-rc2?
Maybe, I wait until Masahiroy has the triple in his kbuild Git tree...
Thanks.
Have a nice Friday,
- sed@ -
[1] https://git.kernel.org/pub/scm/utils/b4/b4.git/tag/?h=v0.8.0
[2] https://git.kernel.org/pub/scm/utils/b4/b4.git/commit/?id=7c1d044ff1d5235e598d4c777c4abfe60e0a09a8
[3] https://github.com/ClangBuiltLinux/linux/wiki/Command-line-tips-and-tricks
On Fri, Mar 4, 2022 at 7:47 AM Sedat Dilek <[email protected]> wrote:
>
> On Thu, Mar 3, 2022 at 6:37 PM Nathan Chancellor <[email protected]> wrote:
> >
> > Hi Sedat,
> >
> > On Thu, Mar 03, 2022 at 07:26:05AM +0100, Sedat Dilek wrote:
> > > Hey Nick!
> > >
> > > This only applies 1/3.
> > >
> > > $ b4 --version
> > > 0.8.0
> > >
> > > $ b4 am https://lore.kernel.org/lkml/[email protected]/
> > > -o - | git am -3
> > > Analyzing 14 messages in the thread
> > > Will use the latest revision: v3
> > > You can pick other revisions using the -vN flag
> > > Checking attestation on all messages, may take a moment...
> > > ---
> > > ✓ [PATCH v3 1/3] Kbuild: move to -std=gnu11
> > > ✓ Signed: DKIM/kernel.org
> > > + Reviewed-by: Nathan Chancellor <[email protected]> (✓ DKIM/kernel.org)
> > > ERROR: missing [2/3]!
> > > ERROR: missing [3/3]!
> > > ---
> > > NOTE: install patatt for end-to-end signature verification
> > > ---
> > > Total patches: 1
> > > ---
> > > WARNING: Thread incomplete!
> > > Link: https://lore.kernel.org/r/[email protected]
> > > Base: not specified
> > > Wende an: Kbuild: move to -std=gnu11
> >
> > It looks like the threading somehow got broken, likely due to the [v3]
> > on the first patch and not the second or third:
> >
> > This worked for me on v5.17-rc6:
> >
> > $ for i in $(seq 1 3); do b4 shazam -P _ 20220301145233.3689119-"$i"[email protected]; done
> >
> > "b4 shazam" is the equivalent of "b4 am -o - ... | git am" and the
> > "-P _" tells b4 to only fetch that exact message ID, not the whole
> > thread.
> >
>
> Hmm, the universe is not good to me...
>
> $ for i in $(seq 1 3); do b4 shazam -P _
> 20220301145233.3689119-"$i"[email protected]; done
> usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
> b4: error: argument subcmd: invalid choice: 'shazam' (choose from
> 'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
> usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
> b4: error: argument subcmd: invalid choice: 'shazam' (choose from
> 'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
> usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
> b4: error: argument subcmd: invalid choice: 'shazam' (choose from
> 'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
>
> Do I need a higher version of b4 (here: v0.8.0)?
>
> Check myself... b4.git:
>
> commit 7c1d044ff1d5235e598d4c777c4abfe60e0a09a8
> ("shazam: change default behaviour to be "apply-here"")
>
> ...is post-v0.8.0.
>
I brutally applied the post-v0.8.0 patches stolen from b4.git over my
local distro b4 files.
And was able to apply the triple:
$ git log --oneline --no-merges
5.17.0-rc6-1-amd64-clang13-lto..5.17.0-rc6-2-amd64-clang13-lto
96a4222bdd4c (for-5.17/kbuild-std_gnu11-arndb-20220301) Kbuild: use
-std=gnu11 for KBUILD_USERCFLAGS
c4e8cef401a8 treewide: use -Wdeclaration-after-statement
6a7cc105b238 Kbuild: move to -std=gnu11
- sed@ -
On Fri, Mar 4, 2022 at 8:18 AM Sedat Dilek <[email protected]> wrote:
>
> On Fri, Mar 4, 2022 at 7:47 AM Sedat Dilek <[email protected]> wrote:
> >
> > On Thu, Mar 3, 2022 at 6:37 PM Nathan Chancellor <[email protected]> wrote:
> > >
> > > Hi Sedat,
> > >
> > > On Thu, Mar 03, 2022 at 07:26:05AM +0100, Sedat Dilek wrote:
> > > > Hey Nick!
> > > >
> > > > This only applies 1/3.
> > > >
> > > > $ b4 --version
> > > > 0.8.0
> > > >
> > > > $ b4 am https://lore.kernel.org/lkml/[email protected]/
> > > > -o - | git am -3
> > > > Analyzing 14 messages in the thread
> > > > Will use the latest revision: v3
> > > > You can pick other revisions using the -vN flag
> > > > Checking attestation on all messages, may take a moment...
> > > > ---
> > > > ✓ [PATCH v3 1/3] Kbuild: move to -std=gnu11
> > > > ✓ Signed: DKIM/kernel.org
> > > > + Reviewed-by: Nathan Chancellor <[email protected]> (✓ DKIM/kernel.org)
> > > > ERROR: missing [2/3]!
> > > > ERROR: missing [3/3]!
> > > > ---
> > > > NOTE: install patatt for end-to-end signature verification
> > > > ---
> > > > Total patches: 1
> > > > ---
> > > > WARNING: Thread incomplete!
> > > > Link: https://lore.kernel.org/r/[email protected]
> > > > Base: not specified
> > > > Wende an: Kbuild: move to -std=gnu11
> > >
> > > It looks like the threading somehow got broken, likely due to the [v3]
> > > on the first patch and not the second or third:
> > >
> > > This worked for me on v5.17-rc6:
> > >
> > > $ for i in $(seq 1 3); do b4 shazam -P _ 20220301145233.3689119-"$i"[email protected]; done
> > >
> > > "b4 shazam" is the equivalent of "b4 am -o - ... | git am" and the
> > > "-P _" tells b4 to only fetch that exact message ID, not the whole
> > > thread.
> > >
> >
> > Hmm, the universe is not good to me...
> >
> > $ for i in $(seq 1 3); do b4 shazam -P _
> > 20220301145233.3689119-"$i"[email protected]; done
> > usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
> > b4: error: argument subcmd: invalid choice: 'shazam' (choose from
> > 'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
> > usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
> > b4: error: argument subcmd: invalid choice: 'shazam' (choose from
> > 'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
> > usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
> > b4: error: argument subcmd: invalid choice: 'shazam' (choose from
> > 'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
> >
> > Do I need a higher version of b4 (here: v0.8.0)?
> >
> > Check myself... b4.git:
> >
> > commit 7c1d044ff1d5235e598d4c777c4abfe60e0a09a8
> > ("shazam: change default behaviour to be "apply-here"")
> >
> > ...is post-v0.8.0.
> >
>
> I brutally applied the post-v0.8.0 patches stolen from b4.git over my
> local distro b4 files.
>
> And was able to apply the triple:
>
> $ git log --oneline --no-merges
> 5.17.0-rc6-1-amd64-clang13-lto..5.17.0-rc6-2-amd64-clang13-lto
> 96a4222bdd4c (for-5.17/kbuild-std_gnu11-arndb-20220301) Kbuild: use
> -std=gnu11 for KBUILD_USERCFLAGS
> c4e8cef401a8 treewide: use -Wdeclaration-after-statement
> 6a7cc105b238 Kbuild: move to -std=gnu11
>
I was able to build and boot on bare metal.
No new warnings in my build-log here after switching to -std=gnu11.
Tested-by: Sedat Dilek <[email protected]> # LLVM/Clang v13.0.0 x86-64
- sed@ -
On Fri, Mar 4, 2022 at 12:12 PM Sedat Dilek <[email protected]> wrote:
>
> On Fri, Mar 4, 2022 at 8:18 AM Sedat Dilek <[email protected]> wrote:
> >
> > On Fri, Mar 4, 2022 at 7:47 AM Sedat Dilek <[email protected]> wrote:
> > >
> > > On Thu, Mar 3, 2022 at 6:37 PM Nathan Chancellor <[email protected]> wrote:
> > > >
> > > > Hi Sedat,
> > > >
> > > > On Thu, Mar 03, 2022 at 07:26:05AM +0100, Sedat Dilek wrote:
> > > > > Hey Nick!
> > > > >
> > > > > This only applies 1/3.
> > > > >
> > > > > $ b4 --version
> > > > > 0.8.0
> > > > >
> > > > > $ b4 am https://lore.kernel.org/lkml/[email protected]/
> > > > > -o - | git am -3
> > > > > Analyzing 14 messages in the thread
> > > > > Will use the latest revision: v3
> > > > > You can pick other revisions using the -vN flag
> > > > > Checking attestation on all messages, may take a moment...
> > > > > ---
> > > > > ✓ [PATCH v3 1/3] Kbuild: move to -std=gnu11
> > > > > ✓ Signed: DKIM/kernel.org
> > > > > + Reviewed-by: Nathan Chancellor <[email protected]> (✓ DKIM/kernel.org)
> > > > > ERROR: missing [2/3]!
> > > > > ERROR: missing [3/3]!
> > > > > ---
> > > > > NOTE: install patatt for end-to-end signature verification
> > > > > ---
> > > > > Total patches: 1
> > > > > ---
> > > > > WARNING: Thread incomplete!
> > > > > Link: https://lore.kernel.org/r/[email protected]
> > > > > Base: not specified
> > > > > Wende an: Kbuild: move to -std=gnu11
> > > >
> > > > It looks like the threading somehow got broken, likely due to the [v3]
> > > > on the first patch and not the second or third:
> > > >
> > > > This worked for me on v5.17-rc6:
> > > >
> > > > $ for i in $(seq 1 3); do b4 shazam -P _ 20220301145233.3689119-"$i"[email protected]; done
> > > >
> > > > "b4 shazam" is the equivalent of "b4 am -o - ... | git am" and the
> > > > "-P _" tells b4 to only fetch that exact message ID, not the whole
> > > > thread.
> > > >
> > >
> > > Hmm, the universe is not good to me...
> > >
> > > $ for i in $(seq 1 3); do b4 shazam -P _
> > > 20220301145233.3689119-"$i"[email protected]; done
> > > usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
> > > b4: error: argument subcmd: invalid choice: 'shazam' (choose from
> > > 'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
> > > usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
> > > b4: error: argument subcmd: invalid choice: 'shazam' (choose from
> > > 'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
> > > usage: b4 [-h] [--version] [-d] [-q] {mbox,am,attest,pr,ty,diff,kr} ...
> > > b4: error: argument subcmd: invalid choice: 'shazam' (choose from
> > > 'mbox', 'am', 'attest', 'pr', 'ty', 'diff', 'kr')
> > >
> > > Do I need a higher version of b4 (here: v0.8.0)?
> > >
> > > Check myself... b4.git:
> > >
> > > commit 7c1d044ff1d5235e598d4c777c4abfe60e0a09a8
> > > ("shazam: change default behaviour to be "apply-here"")
> > >
> > > ...is post-v0.8.0.
> > >
> >
> > I brutally applied the post-v0.8.0 patches stolen from b4.git over my
> > local distro b4 files.
> >
> > And was able to apply the triple:
> >
> > $ git log --oneline --no-merges
> > 5.17.0-rc6-1-amd64-clang13-lto..5.17.0-rc6-2-amd64-clang13-lto
> > 96a4222bdd4c (for-5.17/kbuild-std_gnu11-arndb-20220301) Kbuild: use
> > -std=gnu11 for KBUILD_USERCFLAGS
> > c4e8cef401a8 treewide: use -Wdeclaration-after-statement
> > 6a7cc105b238 Kbuild: move to -std=gnu11
> >
>
> I was able to build and boot on bare metal.
>
> No new warnings in my build-log here after switching to -std=gnu11.
>
> Tested-by: Sedat Dilek <[email protected]> # LLVM/Clang v13.0.0 x86-64
>
I have re-tested with Debian's LLVM/Clang v14.0.0-rc2.
Tested-by: Sedat Dilek <[email protected]> # LLVM/Clang v14.0.0-rc2 (x86-64)
- sed@ -