From: Po-yi Wang <player@vcn.bc.ca>
To: musl@lists.openwall.com
Subject: Re: will this idea work?
Date: Thu, 25 Jan 2018 22:03:35 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.1801252107160.16676@vcn.bc.ca> (raw)
In-Reply-To: <20180126020733.GE1627@brightrain.aerifal.cx>
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@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.
>
> 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
>
next prev parent reply other threads:[~2018-01-26 6:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-25 5:16 Po-yi Wang
2018-01-25 11:22 ` Szabolcs Nagy
2018-01-25 20:09 ` Po-yi Wang
2018-01-25 20:30 ` Rich Felker
2018-01-25 21:31 ` Po-yi Wang
2018-01-26 2:07 ` Rich Felker
2018-01-26 6:03 ` Po-yi Wang [this message]
2018-01-27 22:22 ` A. Wilcox
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=Pine.LNX.4.64.1801252107160.16676@vcn.bc.ca \
--to=player@vcn.bc.ca \
--cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).