mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®