From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Chuck Wolber <chuckwolber@gmail.com>,
openembedded-core@lists.openembedded.org,
Yocto-mailing-list <yocto@yoctoproject.org>
Subject: Re: [OE-core] Hardknott (GCC10) Compiler Issues
Date: Mon, 28 Jun 2021 13:49:41 +0100 [thread overview]
Message-ID: <c48956c8a5358d081fb9e8b9b04cf27848bde756.camel@linuxfoundation.org> (raw)
In-Reply-To: <CAB=6tBQR1S=2niGMojS_55-JebtQX4LybA2aEh_6YNtXf_3yNA@mail.gmail.com>
On Thu, 2021-06-24 at 21:48 -0700, Chuck Wolber wrote:
> All,
>
> Please accept my apologies in advance for the detailed submission. I think
> it is warranted in this case.
>
> There is something... "odd" about the GCC 10 compiler that is delivered with
> Hardknott. I am still chasing it down, so I am not yet ready to declare a
> root cause or submit a bug, but I am posting what I have now in case anyone
> has some insights to offer.
The issue you describe does sound strange. I was a little unclear about exactly
which combinations were passing/failing. Are you saying that some versions of
buildtools let the system work but some do not? We now have gcc 11 in master
so it would be interesting to know how things worked there and if any
regression was fixed.
I have also heard reports of issues with bison segfaulting from other sources
but I don't have anything I can point to specifically about it.
The target system should be independent of buildtools version and the target
system should also be binary reproducible so if that were changing through
changing buildtools tarball, that would be worrying in itself.
> P.P.S. For the sake of completeness, I had to add the following files to the buildtools-extended
> sysroot to fully complete the build of our images:
>
> /usr/include/magic.h -> util-linux "more" command requires this.
> /usr/include/zstd.h -> I do not recall which recipe required this.
> /usr/bin/free -> The OpenJDK 8 build scripts need this.
> /usr/include/sys/* -> openjdk-8-native
> /lib/libcap.so.2 -> The binutils "dir" command quietly breaks the build without this. I am not a fan of the
> lack of error checking in the binutils build...
> /usr/include/sensors/error.h and sensors.h -> mesa-native
> /usr/include/zstd_errors.h -> qemu-system-native
It is great to have this list, outside the non-jdk issues are probably issues we
should look at fixing in OE-Core. Do you mean binutils above for the dir command?
Cheers,
next prev parent reply other threads:[~2021-06-28 12:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-25 4:48 Hardknott (GCC10) Compiler Issues Chuck Wolber
2021-06-25 5:58 ` [yocto] " Zoran
[not found] ` <168BBDBB51FE1C72.20368@lists.yoctoproject.org>
2021-06-25 8:14 ` Zoran
[not found] ` <168BC530899504B6.31827@lists.yoctoproject.org>
2021-06-25 14:59 ` Zoran
2021-06-28 12:49 ` Richard Purdie [this message]
2021-06-28 13:12 ` [yocto] [OE-core] " Zoran
2021-06-28 15:10 ` Zoran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c48956c8a5358d081fb9e8b9b04cf27848bde756.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=chuckwolber@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.