| Message ID | 20230426095036.2632847-5-alex@linutronix.de |
|---|---|
| State | New |
| Headers | show |
| Series | [01/11] binutils: backport a patch to address failures when time64.inc is in use | expand |
On Wed, Apr 26, 2023 at 2:50 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > In particular this enables a number of useful features in glibc, such > as actually using 64 bit time_t versions of kernel syscalls: > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/kernel-features.h;h=07b440f4eea364b05fa49bf71ceebf78f80efe13;hb=HEAD#l164 > > Signed-off-by: Alexander Kanavin <alex@linutronix.de> > --- > meta/conf/bitbake.conf | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf > index afd9e2f5527..2db84a46eed 100644 > --- a/meta/conf/bitbake.conf > +++ b/meta/conf/bitbake.conf > @@ -469,12 +469,7 @@ SDKPATHINSTALL = "/usr/local/${SDK_NAME_PREFIX}-${SDK_ARCH}" > # Kernel info. > ################################################################## > > -OLDEST_KERNEL = "3.2.0" > -OLDEST_KERNEL:aarch64 = "3.14" > -OLDEST_KERNEL:nios2 = "3.19" > -OLDEST_KERNEL:powerpc64le = "3.10.0" > -OLDEST_KERNEL:riscv32 = "5.4" > -OLDEST_KERNEL:riscv64 = "4.15" > +OLDEST_KERNEL = "5.15" > While this might be good, does this fix anything specific for enabling 64bit time_t. This change means we are implying that yocto wont work with kernels older than 5.15 and maybe SDK would also need 5.15 on SDK hosts and similar need for build hosts might be imposed too. Perhaps it would be good to do some due diligence before applying this. > # SDK_OLDEST_KERNEL can't be set using overrides since there are > # none for the SDK architecture. Best to set it from a machine-sdk > -- > 2.30.2 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#180423): https://lists.openembedded.org/g/openembedded-core/message/180423 > Mute This Topic: https://lists.openembedded.org/mt/98511406/1997914 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Thu, 27 Apr 2023 at 09:04, Khem Raj <raj.khem@gmail.com> wrote: > While this might be good, does this fix anything specific for enabling > 64bit time_t. Yes; please see the link. > This change means we are implying that yocto wont work with kernels > older than 5.15 and maybe SDK would also need > 5.15 on SDK hosts and similar need for build hosts might be imposed > too. Perhaps it would be good to do some due diligence before > applying this. I was waiting for someone to say something like this. :) SDKs are not affected. There's a separate setting for them, SDK_OLDEST_KERNEL which stays as it was, at 3.2.0. Kernels versions on build hosts don't have a setting or check, and that never causes trouble. The focus here is specifically on removing all uses of 32 bit time on 32 bit targets, and as a bonus, enabling other optimized paths in glibc that are only supported with newer kernels. The implication is not that yocto won't work with < 5.15, it's that it is not tested with such kernels. Which is fair enough, isn't it? If someone does need an older kernel (and yes, I'm waiting for the 'outdated vendor kernels' squad to come out and lynch me for this change), they can reset OLDEST_KERNEL locally, which would confirm that they should be doing their own testing. Alex
Does this mean that SANITY_TESTED_DISTROS should also be updated to remove all distros with kernel older than 5.15? Regards, Qi -----Original Message----- From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Alexander Kanavin Sent: Thursday, April 27, 2023 3:20 PM To: Khem Raj <raj.khem@gmail.com> Cc: openembedded-core@lists.openembedded.org; Alexander Kanavin <alex@linutronix.de> Subject: Re: [OE-core] [PATCH 05/11] bitbake.conf: set minimum required kernel to 5.15 On Thu, 27 Apr 2023 at 09:04, Khem Raj <raj.khem@gmail.com> wrote: > While this might be good, does this fix anything specific for enabling > 64bit time_t. Yes; please see the link. > This change means we are implying that yocto wont work with kernels > older than 5.15 and maybe SDK would also need > 5.15 on SDK hosts and similar need for build hosts might be imposed > too. Perhaps it would be good to do some due diligence before applying > this. I was waiting for someone to say something like this. :) SDKs are not affected. There's a separate setting for them, SDK_OLDEST_KERNEL which stays as it was, at 3.2.0. Kernels versions on build hosts don't have a setting or check, and that never causes trouble. The focus here is specifically on removing all uses of 32 bit time on 32 bit targets, and as a bonus, enabling other optimized paths in glibc that are only supported with newer kernels. The implication is not that yocto won't work with < 5.15, it's that it is not tested with such kernels. Which is fair enough, isn't it? If someone does need an older kernel (and yes, I'm waiting for the 'outdated vendor kernels' squad to come out and lynch me for this change), they can reset OLDEST_KERNEL locally, which would confirm that they should be doing their own testing. Alex
On Thu, 27 Apr 2023 at 09:30, Chen, Qi <Qi.Chen@windriver.com> wrote:
> Does this mean that SANITY_TESTED_DISTROS should also be updated to remove all distros with kernel older than 5.15?
No. This check only applies to target kernels built by yocto, not any
of the build host or sdk host kernels.
Alex
On Thu, 27 Apr 2023 at 09:31, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: > > Does this mean that SANITY_TESTED_DISTROS should also be updated to remove all distros with kernel older than 5.15? > > No. This check only applies to target kernels built by yocto, not any > of the build host or sdk host kernels. I should however expand the commit message to make this clear, and better explain where OLDEST_KERNEL is used inside oe-core. Alex
On Thu, Apr 27, 2023 at 12:20 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Thu, 27 Apr 2023 at 09:04, Khem Raj <raj.khem@gmail.com> wrote: > > While this might be good, does this fix anything specific for enabling > > 64bit time_t. > > Yes; please see the link. > > > This change means we are implying that yocto wont work with kernels > > older than 5.15 and maybe SDK would also need > > 5.15 on SDK hosts and similar need for build hosts might be imposed > > too. Perhaps it would be good to do some due diligence before > > applying this. > > I was waiting for someone to say something like this. :) > > SDKs are not affected. There's a separate setting for them, > SDK_OLDEST_KERNEL which stays as it was, at 3.2.0. Kernels versions on > build hosts don't have a setting or check, and that never causes > trouble. The focus here is specifically on removing all uses of 32 bit > time on 32 bit targets, and as a bonus, enabling other optimized paths > in glibc that are only supported with newer kernels. > > The implication is not that yocto won't work with < 5.15, it's that it > is not tested with such kernels. Which is fair enough, isn't it? If > someone does need an older kernel (and yes, I'm waiting for the > 'outdated vendor kernels' squad to come out and lynch me for this > change), they can reset OLDEST_KERNEL locally, which would confirm > that they should be doing their own testing. > It will break compatibility with older kernels because we are telling glibc that we have 5.15 at minimum so it will assume system calls which are available upto and including 5.15 and some of these syscalls may not be available in older kernels by next LTS it might be that 5.15 is commonly used but it still remains a problem for precompiled binaries and libraries etc. sadly > Alex
On Thu, 27 Apr 2023 at 09:48, Khem Raj <raj.khem@gmail.com> wrote: > It will break compatibility with older kernels because we are telling glibc that > we have 5.15 at minimum so it will assume system calls which are available > upto and including 5.15 and some of these syscalls may not be > available in older kernels > by next LTS it might be that 5.15 is commonly used but it still > remains a problem for > precompiled binaries and libraries etc. sadly Once again, this affects target kernels only. There are no new restrictions on the build host or sdk host kernel versions. If you are using an older target kernel, set OLDEST_KERNEL to match. If you are using precompiled items, I'm not sure what the problem would be for them? Alex
I am also seing some segfaults in qemu usermode runs | /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/qemuwrapper: line 2: 1592564 Segmentation fault (core dumped) PSEUDO_UNLOAD=1 qemu-x86_64 -r 5.15 -cpu core2duo -L /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot -E LD_LIBRARY_PATH=/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib:/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib "$@" this happens when building libclc from meta-clang I also saw random build failures in qtbase which is perhaps unrelated but could be this one too Third issue is https://errors.yoctoproject.org/Errors/Details/701889/ I wonder if uninative version of glibc should be first built with this change if we really want to pursue it. Also send a BIG warning to community on breaking this backward compatibility, for some it might be helpful to get this notification now than next year. On Thu, Apr 27, 2023 at 12:54 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Thu, 27 Apr 2023 at 09:48, Khem Raj <raj.khem@gmail.com> wrote: > > > It will break compatibility with older kernels because we are telling glibc that > > we have 5.15 at minimum so it will assume system calls which are available > > upto and including 5.15 and some of these syscalls may not be > > available in older kernels > > by next LTS it might be that 5.15 is commonly used but it still > > remains a problem for > > precompiled binaries and libraries etc. sadly > > Once again, this affects target kernels only. There are no new > restrictions on the build host or sdk host kernel versions. > > If you are using an older target kernel, set OLDEST_KERNEL to match. > If you are using precompiled items, I'm not sure what the problem > would be for them? > > Alex
On Sat, 29 Apr 2023 at 21:28, Khem Raj <raj.khem@gmail.com> wrote: > I wonder if uninative version of glibc should be first built with this > change if we really want to pursue it. I'll take a look at the other issues separately, just wanted to respond here straight away - why would we do that? This change is intended only for the target builds, and uninative glibc should retain the broadest possible compatibility with host kernels. It is controlled via SDK_OLDEST_KERNEL, which is set to 3.2.0 and will remain so. Alex
On Sat, 29 Apr 2023 at 21:28, Khem Raj <raj.khem@gmail.com> wrote: > I am also seing some segfaults in qemu usermode runs > > | /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/qemuwrapper: > line 2: 1592564 Segmentation fault (core dumped) PSEUDO_UNLOAD=1 > qemu-x86_64 -r 5.15 -cpu core2duo -L > /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot > -E LD_LIBRARY_PATH=/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib:/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib > "$@" > > this happens when building libclc from meta-clang Does not reproduce here (qemux86-64/poky/musl/gcc/meta-clang master). > I also saw random build failures in qtbase which is perhaps unrelated > but could be this one too This needs to be investigated on your side. > Third issue is https://errors.yoctoproject.org/Errors/Details/701889/ This is from a misconfigured CI on your side and the error is "clang-16: error: unable to execute command: Segmentation fault (core dumped) clang-16: error: linker command failed due to signal (use -v to see invocation)" which may be unrelated. Is it still happening, and is it going away if this patchset is removed? Alex
On Tue, May 2, 2023 at 1:42 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Sat, 29 Apr 2023 at 21:28, Khem Raj <raj.khem@gmail.com> wrote: > > I am also seing some segfaults in qemu usermode runs > > > > | /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/qemuwrapper: > > line 2: 1592564 Segmentation fault (core dumped) PSEUDO_UNLOAD=1 > > qemu-x86_64 -r 5.15 -cpu core2duo -L > > /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot > > -E LD_LIBRARY_PATH=/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib:/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib > > "$@" > > > > this happens when building libclc from meta-clang > > Does not reproduce here (qemux86-64/poky/musl/gcc/meta-clang master). > > > I also saw random build failures in qtbase which is perhaps unrelated > > but could be this one too > > This needs to be investigated on your side. I see that it is host dependent, it works on debian bullseye but fails with latest archlinux since archlinux is rolling and uptodate it just a matter of time when it starts showing up with one of time based distro releases like fedora or others. > > > Third issue is https://errors.yoctoproject.org/Errors/Details/701889/ > > This is from a misconfigured CI on your side and the error is > > "clang-16: error: unable to execute command: Segmentation fault (core dumped) > clang-16: error: linker command failed due to signal (use -v to see invocation)" > > which may be unrelated. Is it still happening, and is it going away if > this patchset is removed? this have not been tried yet explicitly, I can give it a shot if its not host specific > > Alex
On Tue, May 2, 2023 at 8:01 AM Khem Raj <raj.khem@gmail.com> wrote: > > On Tue, May 2, 2023 at 1:42 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > > > On Sat, 29 Apr 2023 at 21:28, Khem Raj <raj.khem@gmail.com> wrote: > > > I am also seing some segfaults in qemu usermode runs > > > > > > | /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/qemuwrapper: > > > line 2: 1592564 Segmentation fault (core dumped) PSEUDO_UNLOAD=1 > > > qemu-x86_64 -r 5.15 -cpu core2duo -L > > > /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot > > > -E LD_LIBRARY_PATH=/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib:/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib > > > "$@" > > > > > > this happens when building libclc from meta-clang > > > > Does not reproduce here (qemux86-64/poky/musl/gcc/meta-clang master). > > On to this one next. I think it will be good to understand this. > > > I also saw random build failures in qtbase which is perhaps unrelated > > > but could be this one too > > > > This needs to be investigated on your side. > > I see that it is host dependent, it works on debian bullseye but fails > with latest archlinux > since archlinux is rolling and uptodate it just a matter of time when > it starts showing up > with one of time based distro releases like fedora or others. > > > > > > Third issue is https://errors.yoctoproject.org/Errors/Details/701889/ > > > > This is from a misconfigured CI on your side and the error is > > > > "clang-16: error: unable to execute command: Segmentation fault (core dumped) > > clang-16: error: linker command failed due to signal (use -v to see invocation)" > > This seems to be not related to this. which is good news. > > which may be unrelated. Is it still happening, and is it going away if > > this patchset is removed? > > this have not been tried yet explicitly, I can give it a shot if its > not host specific > > > > > Alex
On Wed, May 3, 2023 at 5:36 PM Khem Raj <raj.khem@gmail.com> wrote: > > On Tue, May 2, 2023 at 8:01 AM Khem Raj <raj.khem@gmail.com> wrote: > > > > On Tue, May 2, 2023 at 1:42 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > > > > > On Sat, 29 Apr 2023 at 21:28, Khem Raj <raj.khem@gmail.com> wrote: > > > > I am also seing some segfaults in qemu usermode runs > > > > > > > > | /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/qemuwrapper: > > > > line 2: 1592564 Segmentation fault (core dumped) PSEUDO_UNLOAD=1 > > > > qemu-x86_64 -r 5.15 -cpu core2duo -L > > > > /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot > > > > -E LD_LIBRARY_PATH=/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib:/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib > > > > "$@" > > > > > > > > this happens when building libclc from meta-clang > > > > > > Does not reproduce here (qemux86-64/poky/musl/gcc/meta-clang master). > > > > > On to this one next. I think it will be good to understand this. I built it on debian container and it does not segfault, Then I tried to build it on archlinux ( just recompiling libclc ) and it does not segfault either which means its some dependency ( maybe a library ) which gets compiled differently when compiled on archlinux and causes qemu to segfault. I will do a full scratch build on archlinux and see if it can be reproduced again. > > > > > I also saw random build failures in qtbase which is perhaps unrelated > > > > but could be this one too > > > > > > This needs to be investigated on your side. > > > > I see that it is host dependent, it works on debian bullseye but fails > > with latest archlinux > > since archlinux is rolling and uptodate it just a matter of time when > > it starts showing up > > with one of time based distro releases like fedora or others. > > > > > > > > > Third issue is https://errors.yoctoproject.org/Errors/Details/701889/ > > > > > > This is from a misconfigured CI on your side and the error is > > > > > > "clang-16: error: unable to execute command: Segmentation fault (core dumped) > > > clang-16: error: linker command failed due to signal (use -v to see invocation)" > > > > > This seems to be not related to this. which is good news. > > > > which may be unrelated. Is it still happening, and is it going away if > > > this patchset is removed? > > > > this have not been tried yet explicitly, I can give it a shot if its > > not host specific > > > > > > > > Alex
On Wed, May 3, 2023 at 6:14 PM Khem Raj <raj.khem@gmail.com> wrote: > > On Wed, May 3, 2023 at 5:36 PM Khem Raj <raj.khem@gmail.com> wrote: > > > > On Tue, May 2, 2023 at 8:01 AM Khem Raj <raj.khem@gmail.com> wrote: > > > > > > On Tue, May 2, 2023 at 1:42 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > > > > > > > On Sat, 29 Apr 2023 at 21:28, Khem Raj <raj.khem@gmail.com> wrote: > > > > > I am also seing some segfaults in qemu usermode runs > > > > > > > > > > | /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/qemuwrapper: > > > > > line 2: 1592564 Segmentation fault (core dumped) PSEUDO_UNLOAD=1 > > > > > qemu-x86_64 -r 5.15 -cpu core2duo -L > > > > > /mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot > > > > > -E LD_LIBRARY_PATH=/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib:/mnt/b/yoe/master/build/tmp/work/core2-64-yoe-linux-musl/libclc/16.0.1-r0/recipe-sysroot/usr/lib > > > > > "$@" > > > > > > > > > > this happens when building libclc from meta-clang > > > > > > > > Does not reproduce here (qemux86-64/poky/musl/gcc/meta-clang master). > > > > > > > > On to this one next. I think it will be good to understand this. > > I built it on debian container and it does not segfault, Then I tried > to build it on archlinux ( just recompiling libclc ) and it does not > segfault either which means its some dependency ( maybe a library ) > which gets compiled differently when compiled on archlinux and causes > qemu to segfault. I will do a full scratch build on archlinux and see > if it can be reproduced again. It worked with scratch build, however its not same archlinux as last week. GCC got upgraded to 13.x and i had to disable uninative so it might still be hidden there for now lets ignore it > > > > > > > > I also saw random build failures in qtbase which is perhaps unrelated > > > > > but could be this one too > > > > > > > > This needs to be investigated on your side. > > > > > > I see that it is host dependent, it works on debian bullseye but fails > > > with latest archlinux > > > since archlinux is rolling and uptodate it just a matter of time when > > > it starts showing up > > > with one of time based distro releases like fedora or others. > > > > > > > > > > > > Third issue is https://errors.yoctoproject.org/Errors/Details/701889/ > > > > > > > > This is from a misconfigured CI on your side and the error is > > > > > > > > "clang-16: error: unable to execute command: Segmentation fault (core dumped) > > > > clang-16: error: linker command failed due to signal (use -v to see invocation)" > > > > > > > > This seems to be not related to this. which is good news. > > > > > > which may be unrelated. Is it still happening, and is it going away if > > > > this patchset is removed? > > > > > > this have not been tried yet explicitly, I can give it a shot if its > > > not host specific > > > > > > > > > > > Alex
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index afd9e2f5527..2db84a46eed 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -469,12 +469,7 @@ SDKPATHINSTALL = "/usr/local/${SDK_NAME_PREFIX}-${SDK_ARCH}" # Kernel info. ################################################################## -OLDEST_KERNEL = "3.2.0" -OLDEST_KERNEL:aarch64 = "3.14" -OLDEST_KERNEL:nios2 = "3.19" -OLDEST_KERNEL:powerpc64le = "3.10.0" -OLDEST_KERNEL:riscv32 = "5.4" -OLDEST_KERNEL:riscv64 = "4.15" +OLDEST_KERNEL = "5.15" # SDK_OLDEST_KERNEL can't be set using overrides since there are # none for the SDK architecture. Best to set it from a machine-sdk
In particular this enables a number of useful features in glibc, such as actually using 64 bit time_t versions of kernel syscalls: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/kernel-features.h;h=07b440f4eea364b05fa49bf71ceebf78f80efe13;hb=HEAD#l164 Signed-off-by: Alexander Kanavin <alex@linutronix.de> --- meta/conf/bitbake.conf | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)