On Sat, 1 Aug 2020 at 19:40, Sumit Garg via lists.yoctoproject.org
<sumit.garg=linaro.org(a)lists.yoctoproject.org> wrote:
>
> On Sat, 1 Aug 2020 at 14:57, Ryan Harkin <ryan.harkin(a)linaro.org> wrote:
> >
> >
> >
> > On Sat, 1 Aug 2020 at 10:09, Ryan Harkin <ryan.harkin(a)linaro.org> wrote:
> >>
> >> Hi Khem,
> >>
> >> On Fri, 31 Jul 2020, 21:58 Khem Raj, <raj.khem(a)gmail.com> wrote:
> >>>
> >>> On Fri, Jul 31, 2020 at 8:35 AM Ryan Harkin <ryan.harkin(a)linaro.org> wrote:
> >>> >
> >>> > Hello,
> >>> >
> >>> > I'm migrating from Warrior to Dunfell and I'm getting a curious build failure in gcc-sanitizers.
> >>> >
> >>> > Here's the full gory detail:
> >>> > https://pastebin.ubuntu.com/p/nh4cDKMvgS/
> >>> >
> >>> > However, the main error is this:
> >>> >
> >>> > | In file included from ../../../../../../../../../work-shared/gcc-arm-8.3-r2019.03/git/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:193:
> >>> > | ../../../../../../../../../work-shared/gcc-arm-8.3-r2019.03/git/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:317:72: error: size of array 'assertion_failed__1152' is negative
> >>> > | typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
> >>> >
> >>> > I have no idea where to begin with this. I don't even know why gcc-sanitizers is included in the build, what it does, or why I need it. I'm building an image with dev packages and gcc, so I guess that's why.
> >>> >
> >>> > I've hacked meta-arm to patch sanitizer_platform_limits_posix.cc to null out the macros and that builds fine. I'm sure it won't work, should someone want to use it, mind you.
> >>> >
> >>> > Is there something obvious that I should be doing as part of a Warrior -> Dunfell migration to get this to work?
> >>> >
> >>> > note: Warrior used meta-linaro-toolchain and for Dunfell, it's moved to meta-arm-toolchain.
> >>> >
> >>>
> >>> is gcc 8.3 the latest for linaro
> >>
> >>
> >> I assume so. I haven't attempted to change the default.
> >
> >
> > I'm sorry, that's incorrect: local.conf has an over-ride to specify 8.3.
> > I've just removed it and now it's using 9.3. And it's building fine.
> >
It's using GCC 9.3 from OE core. If you wish to use Arm toolchain then
you need to override the default OE core GCC version with Arm
toolchain GCC version:
GCCVERSION = "arm-9.2"
-Sumit
> > Sumit, do you know if there's a reason for using 9.2 in RPB instead of 9.3?
> >
>
> Arm GCC 9.3 toolchain isn't released yet (see here [1]).
>
> [1] https://developer.arm.com/tools-and-software/open-source-software/developer…
>
> -Sumit
>
> >>
> >>>
> >>> > Regards,
> >>> > Ryan.
> >>> >
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#50161): https://lists.yoctoproject.org/g/yocto/message/50161
> Mute This Topic: https://lists.yoctoproject.org/mt/75909560/1777089
> Group Owner: yocto+owner(a)lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [sumit.garg(a)linaro.org]
> -=-=-=-=-=-=-=-=-=-=-=-
Hello,
I'm migrating from Warrior to Dunfell and I'm getting a curious build
failure in gcc-sanitizers.
Here's the full gory detail:
https://pastebin.ubuntu.com/p/nh4cDKMvgS/
However, the main error is this:
| In file included from
../../../../../../../../../work-shared/gcc-arm-8.3-r2019.03/git/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:193:
|
../../../../../../../../../work-shared/gcc-arm-8.3-r2019.03/git/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:317:72:
error: size of array 'assertion_failed__1152' is negative
| typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
I have no idea where to begin with this. I don't even know why
gcc-sanitizers is included in the build, what it does, or why I need it.
I'm building an image with dev packages and gcc, so I guess that's why.
I've hacked meta-arm to patch sanitizer_platform_limits_posix.cc to null
out the macros and that builds fine. I'm sure it won't work, should someone
want to use it, mind you.
Is there something obvious that I should be doing as part of a Warrior ->
Dunfell migration to get this to work?
note: Warrior used meta-linaro-toolchain and for Dunfell, it's moved to
meta-arm-toolchain.
Regards,
Ryan.
Hello!
I mentioned a few weeks back that I had some doubts on the difference
between this override:
SRCREV_kernel = "5821a5593fa9f28eb6fcc95c35d00454d9bb8624"
and this one:
SRCREV_kernel_juno = "5821a5593fa9f28eb6fcc95c35d00454d9bb8624"
The following is the definition in the kernel recipe itself:
SRCREV_kernel = "3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162"
Turns out that with _only_ the first override in local.conf (without
MACHINE), the kernel uses the right SRCREV but Perf uses the one from
the recipe; I have to include the second override (with MACHINE) so
that Perf can use the right SRCREV.
Does anyone have a pointer that could shed more light on that subject?
Thanks and greetings!
Daniel Díaz
daniel.diaz(a)linaro.org
On Fri, 10 Apr 2020 at 23:11, Jon Mason <jdmason(a)kudzu.us> wrote:
>
> On Fri, Apr 10, 2020 at 06:05:57PM +0200, Nicolas Dechesne wrote:
> > hi there,
> >
> > over the last few months, we've transitioned the gcc-arm toolchain from
> > meta-linaro-toolchain for master. Since we are approaching the next YP
> > release, I would like to remove/cleanup recipes in meta-linaro-toolchain
> > before we create the dunfell branch.
> >
> > as of now, meta-linaro-toolchain has the following recipes:
> > gcc_arm-8.2.bb
> > gcc_arm-8.3.bb
> > gcc_arm-9.2.bb
> > gcc_linaro-7.2.bb
> >
> > including all their usual dependencies, and the 'external' toolchain
> > recipes.
> >
> > meta-arm-toolchain has
> > gcc_arm-8.2.bb
> > gcc_arm-8.3.bb
> > gcc_arm-9.2.bb
> >
> > and it's strictly the same metadata, as of now.
> >
> > As such, I am proposing to remove all recipes from meta-linaro-toolchain
> > master branch, and require every user to transition to meta-arm.
> >
> > it will effectively become an empty layer.. so I have 2 options:
> > 1. keep an empty layer with conf/layer.conf
> > 2. remove the layer completely (e.g. remote meta-linaro-toolchain folder)
> >
> > I am not sure which one is better.. #2 will generate an obvious error
> > message for anyone using the layer. Maybe that would be a strong signal..
> >
> > I will default to #2 right before we create the dunfell branch (in a couple
> > of weeks max), unless someone speaks before that!
>
> I agree with you that #2 is the correct choice (in case you were
> wanting a secondary opinion).
>
+1
-Sumit
> Thanks,
> Jon
>
> >
> > Nothing will change of course for our stable branches.
> >
> > cheers
> > nico
>
> >
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#196): https://lists.yoctoproject.org/g/meta-arm/message/196
> Mute This Topic: https://lists.yoctoproject.org/mt/72924576/1777089
> Group Owner: meta-arm+owner(a)lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-arm/leave/7647878/863301594/xyzzy [sumit.garg(a)linaro.org]
> -=-=-=-=-=-=-=-=-=-=-=-
hi there,
over the last few months, we've transitioned the gcc-arm toolchain from
meta-linaro-toolchain for master. Since we are approaching the next YP
release, I would like to remove/cleanup recipes in meta-linaro-toolchain
before we create the dunfell branch.
as of now, meta-linaro-toolchain has the following recipes:
gcc_arm-8.2.bb
gcc_arm-8.3.bb
gcc_arm-9.2.bb
gcc_linaro-7.2.bb
including all their usual dependencies, and the 'external' toolchain
recipes.
meta-arm-toolchain has
gcc_arm-8.2.bb
gcc_arm-8.3.bb
gcc_arm-9.2.bb
and it's strictly the same metadata, as of now.
As such, I am proposing to remove all recipes from meta-linaro-toolchain
master branch, and require every user to transition to meta-arm.
it will effectively become an empty layer.. so I have 2 options:
1. keep an empty layer with conf/layer.conf
2. remove the layer completely (e.g. remote meta-linaro-toolchain folder)
I am not sure which one is better.. #2 will generate an obvious error
message for anyone using the layer. Maybe that would be a strong signal..
I will default to #2 right before we create the dunfell branch (in a couple
of weeks max), unless someone speaks before that!
Nothing will change of course for our stable branches.
cheers
nico
