[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180126020733.GE1627@brightrain.aerifal.cx>
Date: Thu, 25 Jan 2018 21:07:33 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: will this idea work?
On Thu, Jan 25, 2018 at 01:31:38PM -0800, Po-yi Wang wrote:
>
>
> On Thu, 25 Jan 2018, Rich Felker wrote:
>
> >On Thu, Jan 25, 2018 at 12:09:27PM -0800, Po-yi Wang wrote:
> >>
> >>
> >>On Thu, 25 Jan 2018, Szabolcs Nagy wrote:
> >>
> >>>* Po-yi Wang <player@....bc.ca> [2018-01-24 21:16:15 -0800]:
> >>>>the current version of musl (1.1.18), will no longer work with older
> >>>>binutils and gcc, specifically, the arm target. both i486 and ppc seem ok.
> >>>>i have checked older versions of musl, i guess some of them must have worked
> >>>>with gcc-3 binutils-1.15 before. suppose i try to port musl to work with
> >> (binutils-2.15)(typo)
> >>>>older tools, specially gcc-3.4.5 and binutils-1.15. also assuming, only need
> >> (binutils-2.15)(typo)
> >>>>to support older cpu and nothing new. i am guessing porting all the assembly
> >>>>files (*.s) would be sufficient?
> >>>
> >>>yes, porting the asm works, but note that the old
> >>>vfp intrinsics that work in binutils don't work in
> >>>llvm (complain to llvm folks) so it's not possible
> >>>to write asm such that every tool is happy, you
> >>>will need to do some ifdef clang hackery and i'm
> >>>not sure if the '.object_arch' directive works with
> >>>that old binutils.
> >>>
> >>i scanned through the musl mailing list archive, it seemed that
> >> the minimum supported binutils version has been discussed before,
> >>around October 15, 2015. what is the current recommended
> >>gcc+binutils
> >>version that can support 486,armv5,ppc750?
> >
> >In general, old versions of both binutils and gcc have lots of unfixed
> >bugs, and it's hard to assess completely whether musl will be
> >affected. Non-x86 platforms are much less tested in combination with
> >outdated tools. I would highly recommend against running binutils
> >versions much older than 2.20 or so, and ideally you should be using
> >2.25 or later.
> >
> >Is there a reason you really want to use old versions?
> not at all, i do not mind using binutils-2.24 for example, except
> old gcc (gcc-3.x) will probably not consent to work with it.
> working with new tools require extensive testing.
I don't know any reason to expect old gcc to fail with new binutils.
New versions of binutils have to accept old .o files (e.g. from old .a
library archives) and asm hand-written for old versions of the
assembler, etc. and all gcc does is feed asm to the assembler.
> it would be best to work with known tools, if no new requirement
> asked for.
> besides, new tools normally demand more resources--memory for example.
This is definitely true of gcc, but not nearly as much so for
binutils.
> newer binutils, for example, require new patches to conserve memory...
> it is not imperative, but if i have the time or will, i like to see
> some old hardware can compile on its own, un-assisted by 16G equipped
> x86-64, few simple tools. it used to be possible. so what has changed?
> new tools might have new bugs.
Maintainership of GNU projects (especially glibc but also gcc and
binutils) was a huge mess until something like 5-7 years ago. Yes,
you're right that some new bugs get added too, but before there were
stupid bugs that went ignored for decades. Modern GNU tools really are
better than old ones in terms of quality/bugs, but do have some costs
like C++ and increased bloat.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
