Re: will this idea work?

[Po-yi Wang <player@vcn.bc.ca>]

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@vcn.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.
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.
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. 
>
> Rich
>