linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: "Måns Rullgård" <mans@mansr.com>
Cc: Pavel Machek <pavel@ucw.cz>, Will Deacon <will.deacon@arm.com>,
	Trivial patch monkey <trivial@kernel.org>,
	Andrew Morton <akpm@osdl.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>
Subject: Re: new binutils needed for arm in 3.12-rc1
Date: Tue, 24 Sep 2013 16:23:48 -0500	[thread overview]
Message-ID: <1380057828.1974.73@driftwood> (raw)
In-Reply-To: <yw1xpprywhad.fsf@unicorn.mansr.com> (from mans@mansr.com on Tue Sep 24 07:11:38 2013)

On 09/24/2013 07:11:38 AM, Måns Rullgård wrote:
> Rob Landley <rob@landley.net> writes:
> 
> > On 09/23/2013 06:59:17 PM, Pavel Machek wrote:
> >> During 3.12-rc, Will Deacon introduced code into arch/arm that
> >> requires binutils 2.22.
> >
> > Um, my toolchain is using the last gplv2 snapshot of binutils out of
> > git, which is just past 2.17 and can build armv7 (but not armv8).
> >
> > Binutils 2.12->2.22 is quite the jump. (11 years.) I'd except some
> > thought to have gone into that? Possibly a mention of it?
> 
> I seriously doubt that 2.12 still works at all (I doubt it can even be
> built on a modern system).  In my experience, binutils older than 2.19
> or so rarely works properly for ARM.

I've been building every kernel release with 2.17 for several years, on  
a bunch of different architectures. Toolchain releases after that are  
GPLv3* and I can't distribute those binaries, so I can't ship prebuilt  
binary toolchains.

(Lots of other people produce cross compilers, but nobody else seems to  
produce prebuilt statically linked _native_ compilers. It would be nice  
if they did.)

> What value is there in maintaining compatibility with a truly ancient
> binutils version anyway?

What value is there in requiring the new toolchain? From what I could  
see of the commits it was micro-optimizations around memory barriers.

*shrug* I can revert the patch locally, or patch the extra instruction  
into my toolchain. But I do object to changing the documentation  
globally for every architecture because one architecture did something  
they apparently never thought through (or they'd have commented in the  
commit that it requires a big toolchain version jump; pretty sure they  
didn't actually notice).

Rob

* The Free Software Foundation got so pissed that MacOS X and BSD and  
such were sticking with the last GPLv2 release of binutils that they  
deleted the binutils tarball off their website and replaced it with one  
including GPLv3 source code. Check the FTP site if you don't believe  
me. Some of us have it snapshotted though. In my case, I actually  
fished the last GPLv2 version out of source control, right before the  
license change was committed, because I wanted armv7 support.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

  reply	other threads:[~2013-09-24 21:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-19  9:30 3.12-rc1: no longer compiles for Nokia n900 (omap based) Pavel Machek
2013-09-19  9:36 ` Will Deacon
2013-09-19  9:57   ` Pavel Machek
2013-09-23 23:59   ` new binutils needed for arm in 3.12-rc1 Pavel Machek
2013-09-24  2:13     ` Rob Landley
2013-09-24 12:11       ` Måns Rullgård
2013-09-24 21:23         ` Rob Landley [this message]
2013-09-24 21:48           ` Russell King - ARM Linux
2013-09-25  1:13             ` Rob Landley
2013-09-25  2:07               ` Nicolas Pitre
2013-09-25 15:23                 ` Rob Landley
2013-09-25 15:52                   ` Måns Rullgård
2013-09-26  0:10                     ` Rob Landley
2013-09-26 22:24                       ` Måns Rullgård
2013-09-25 16:13                   ` Nicolas Pitre
2013-09-26 22:48                     ` Rob Landley
2013-09-27 19:41                       ` Pavel Machek
2013-09-28  8:43                       ` Pavel Machek
2013-09-25 20:44                   ` Russell King - ARM Linux
2013-09-25 20:49                     ` Måns Rullgård
2013-09-26 22:50                       ` Rob Landley
2013-09-26  7:18               ` Geert Uytterhoeven
2013-09-28  9:03                 ` richard -rw- weinberger
2013-09-24  2:20     ` Rob Landley
2013-09-19  9:44 ` 3.12-rc1: no longer compiles for Nokia n900 (omap based), display no longer works Pavel Machek
2013-09-19 18:47   ` Aaro Koskinen
2013-09-26  0:23     ` Pavel Machek

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=1380057828.1974.73@driftwood \
    --to=rob@landley.net \
    --cc=Catalin.Marinas@arm.com \
    --cc=akpm@osdl.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mans@mansr.com \
    --cc=pavel@ucw.cz \
    --cc=torvalds@linux-foundation.org \
    --cc=trivial@kernel.org \
    --cc=will.deacon@arm.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;
as well as URLs for NNTP newsgroup(s).