From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12405 Path: news.gmane.org!.POSTED!not-for-mail From: Po-yi Wang Newsgroups: gmane.linux.lib.musl.general Subject: Re: will this idea work? Date: Thu, 25 Jan 2018 22:03:35 -0800 (PST) Message-ID: References: <20180125112249.GE4418@port70.net> <20180125203045.GD1627@brightrain.aerifal.cx> <20180126020733.GE1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Trace: blaine.gmane.org 1516946520 12078 195.159.176.226 (26 Jan 2018 06:02:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Jan 2018 06:02:00 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12421-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 26 07:01:56 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1eex5C-0002VE-C1 for gllmg-musl@m.gmane.org; Fri, 26 Jan 2018 07:01:50 +0100 Original-Received: (qmail 21753 invoked by uid 550); 26 Jan 2018 06:03:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 21726 invoked from network); 26 Jan 2018 06:03:48 -0000 In-Reply-To: <20180126020733.GE1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12405 Archived-At: 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 [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 >