| Message ID | 20130923235917.GA30967@amd.pavel.ucw.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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. I'm sorry, it occurs to me I should have been more explicit: AAAAAAAAAAAAAAAAHHHHHHHHHH!!!!!!!!!!!!!!!!! KILL IT WITH FIRE!!!!!!!!!!!!!!! Rob-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. What value is there in maintaining compatibility with a truly ancient binutils version anyway?
On Tue, Sep 24, 2013 at 04:23:48PM -0500, Rob Landley wrote: > 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). Some of us are notoriously slow at updating our toolchains. I'm still using gcc 4.5.4 here, and people regard that as bordering on "too old" because of the amount of warnings it spits out. Binutils? I upgraded to 2.22 when I needed to fix a problem I was having with the previous binutils I was using (I think that was 2.18). I generally don't touch my toolchain unless there's a _reason_ I need to, and as I've already updated to 2.22, it's a normally a pretty safe bet that everyone else is already using 2.22 or later. One reason for this is that I don't want to be messing around trying to work out whether a bug I'm seeing is because of a toolchain problem or something in the kernel. I realised at the time that I'm going to got shouted at if I accepted the patches by a minority who wanted to keep their old toolchains, but I also realise that if I don't accept the patches, I'll get shouted at by another group. It's the classic damned if I do and damned if I don't. So I've chosen the lesser of the two weavels. Now, if you feel strongly about this, we _could_ introduce a CONFIG_OLD_BINUTILS and give everyone their cake - but it will be fragile. Not everyone will remember to get that right, because they'll be using the later binutils. Also, we already have an excessive number of potential breakage-inducing options and we certainly don't need another. Use IS_ENABLED() I hear you say. That won't get the one dsb instruction in some SoC code which was missed which will break the build on older toolchains. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, On Wed, Sep 25, 2013 at 3:13 AM, Rob Landley <rob@landley.net> wrote: > Some of us can't ship GPLv3 binaries and are looking forward to the day LLVM > or some such provides a complete solution. Sorry, I didn't have a coffee yet, but which subtility am I missing that prohibits you from shipping GPLv3 binaries? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 26, 2013 at 9:18 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Rob, > > On Wed, Sep 25, 2013 at 3:13 AM, Rob Landley <rob@landley.net> wrote: >> Some of us can't ship GPLv3 binaries and are looking forward to the day LLVM >> or some such provides a complete solution. > > Sorry, I didn't have a coffee yet, but which subtility am I missing > that prohibits > you from shipping GPLv3 binaries? /me had coffee but still doesn't get why you can't ship GPLv3 binaries. Rob, can you please enlighten us?
diff --git a/Documentation/Changes b/Documentation/Changes index b175808..0f8deaf 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -23,7 +23,7 @@ you probably needn't concern yourself with isdn4k-utils. o Gnu C 3.2 # gcc --version o Gnu make 3.80 # make --version -o binutils 2.12 # ld -v +o binutils 2.22 # ld -v o util-linux 2.10o # fdformat --version o module-init-tools 0.9.10 # depmod -V o e2fsprogs 1.41.4 # e2fsck -V
During 3.12-rc, Will Deacon introduced code into arch/arm that requires binutils 2.22. Signed-off-by: Pavel Machek <pavel@ucw.cz> --- Or that changes should be reverted. I have updated my buildsystem on main machine, but ... it seems that debian-cross repository does not contain new enough bintuils for kernel now. We are talking 62cbbc42e0019aff6310259f275ae812463f8836 6af396a6b6c698eb3834184518fc9a59bc22c817 73a6fdc48bf52e93c26874dc8c0f0f8d5585a809 6abdd491698a27f7df04a32ca12cc453810e4396