[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Jan 2018 22:03:35 -0800 (PST)
From: Po-yi Wang <player@....bc.ca>
To: musl@...ts.openwall.com
Subject: Re: will this idea work?
On Thu, 25 Jan 2018, Rich Felker wrote:
> 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.
i had started earlier compiling on new binutils, and hoping the old
binutils could manage and merge .o files from new version (only for *.s).
but no, old binutils would complain about mismatched something.
i thought, maybe porting *.s was the only option left.
i did notice something though, it seems musl build script would build
for echo source file a ".o" and a ".lo". but they are exactly the same,
for the few files i tested...
you are right, i just tested your idea, and it worked!
i simply overwrite the old binutils with newer version.
everything seems to work ok. i thought they invented new "EABI",
and broke compatibility. now, no porting is required!
now i get:
"ELF 32-bit LSB executable, ARM, version 1, statically linked, stripped"
instead of:
"ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically
linked, stripped"
thanks.
gcc2+(musl-c89)?
>
>> 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.
