From: Guenter Roeck <linux@roeck-us.net>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
Tony Breeds <tony@bakeyournoodle.com>,
LKML <linux-kernel@vger.kernel.org>,
LAKML <linux-arm-kernel@lists.infradead.org>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: Updating kernel.org cross compilers?
Date: Tue, 9 May 2017 09:26:55 -0700 [thread overview]
Message-ID: <20170509162655.GB14061@roeck-us.net> (raw)
In-Reply-To: <ee8a7f2c-976d-fe2a-55f9-ab8eebbf22eb@arm.com>
On Tue, May 09, 2017 at 03:59:27PM +0100, Andre Przywara wrote:
> On 30/04/17 06:29, Segher Boessenkool wrote:
>
> Hi,
>
> > On Wed, Apr 26, 2017 at 03:14:16PM +0100, Andre Przywara wrote:
> >> It seems that many people (even outside the Linux kernel community) use
> >> the cross compilers provided at kernel.org/pub/tools/crosstool.
> >> The latest compiler I find there is 4.9.0, which celebrated its third
> >> birthday at the weekend, also has been superseded by 4.9.4 meanwhile.
> >>
> >> So I took Segher's buildall scripts from [1] and threw binutils 2.28 and
> >> GCC 6.3.0 at them.
> >
> > Happy to see people are still using these!
> >
> >> After removing --enable-sjlj-exceptions from build-gcc
> >
> > This was needed to build some targets. It does prevent aarch64 from
> > building without patch.
>
> I saw you fixing that in your repo, thanks for that!
>
> >> and adding --disable-multilib (for building x86-64 on a x86-64
> >> box without 32-bit libs)
> >
> > Why is this needed? What error are you seeing.
>
> It was something along the lines of not finding 32-bit compat libraries
> (which I don't have on that build machine):
> ------------------------
> configure: error: I suspect your system does not have 32-bit development
> libraries (libc and headers). If you have them, rerun configure with
> --enable-multilib. If you do not have them, and want to build a
> 64-bit-only compiler, rerun configure with --disable-multilib.
> ------------------------
>
> I don't think we need multilib for a kernel build, also we have an i386
> compiler for 32-bit kernels. So adding this flags allows x86_64 to be
> build on pure 64-bit systems.
>
> >> I was able to build (bare-metal) toolchains for
> >> all architectures except arc, m68k, tilegx and tilepro.
> >
> > arc needs a more recent GCC; the other probably as well. GCC 7 should
> > be out very soon, you probably want to wait for that :-)
>
> Well, GCC 7 indeed builds better, but then again is a very new compiler.
> For instance in the moment it spits a lot of warnings when compiling the
> kernel (mostly due to some *printf analysis). It's not hard to fix, but
> this will take a while to trickle in and it's questionable whether this
> will be backported everywhere.
> So in addition to GCC 7.1 I'd like to have at least GCC 6.3 around,
> which builds kernels without warnings today.
>
> For GCC 6.3 (and probably before) arc was breaking because missing a
> (default) CPU type. Adding "--with-cpu=arc700" to EXTRA_GCC_CONF fixed
> that, but GCC 7 indeed builds fine, even without it.
> I was wondering if we could have that flags added to the new
> TARGET_GCC_CONF variable for arc-elf, to cover pre GCC 7 compilers.
>
I think arcv2 requires gcc 7.
> >> $ ./buildall --toolchain
> >> $ PATH=$PATH:/opt/cross/bin
> >> $ ./buildall --kernel
> >
> > You should have the target dir in your PATH before doing anything else.
> > Is this not documented? Hrm I guess not, let me fix that.
> >
> >> And what is a good build setup, so that the binaries run on as many
> >> systems as possible?
> >
> > Run contrib/download_prerequisites in the gcc source dir: this will
> > make GMP, MPFR, MPC statically linked, and use a version of each that
> > is known to work (and work correctly).
>
> Ah, that's a good hint! Thanks, that solves a lot of problems.
>
> Also I removed documentation (share/ directory, which won't be in
> MANPATH mostly anyway) from the tarball and stripped the (host) binaries
> to get the tarball size down (to about 16 MB per arch)
>
> I built both toolchains and kernels for almost all 31 supported
> architectures. Some kernel builds fails (sparc, sparc64, arc), but not
Are those missing libgcc ? If so, I think it is a toolchain issue.
I solved it by adding all-target-libgcc / install-target-libgcc
to the build (and installing the kernel headers where needed, ie for
m68k and tilegx/tilepro).
> So while I have now 31 GCC 7.1.0 tarballs, pushing those binaries to
> due to toolchain issues, as it seems. Only sh4 complains:
> sh4-linux-gcc: error: command line option '-m4-nofpu' is not supported
What configuration are you trying to build, and how does your make command
line look like (wondering, because I don't see the problem) ?
> by this configuration.
> some public webspace raises some legal eyebrows here, so I was wondering
> if someone (probably with less affiliation to a hardware (arch) vendor)
> could build, package and upload them? I am happy to assist with that
> process.
>
How do you create the per-target tarballs ? The script in the
repository pushes eherything into a single target directory.
Thanks,
Guenter
next prev parent reply other threads:[~2017-05-09 16:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-26 14:14 Andre Przywara
2017-04-30 3:37 ` Guenter Roeck
2017-04-30 5:29 ` Segher Boessenkool
2017-05-09 14:59 ` Andre Przywara
2017-05-09 16:26 ` Guenter Roeck [this message]
2017-05-09 22:18 ` Segher Boessenkool
2017-05-10 7:58 ` Arnd Bergmann
2017-05-10 13:40 ` Segher Boessenkool
2017-05-10 19:32 ` Arnd Bergmann
2017-05-23 18:15 ` Chris Metcalf
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=20170509162655.GB14061@roeck-us.net \
--to=linux@roeck-us.net \
--cc=andre.przywara@arm.com \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=segher@kernel.crashing.org \
--cc=tony@bakeyournoodle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®