will this idea work?

will this idea work?

[Po-yi Wang]

hi

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 older tools, specially gcc-3.4.5 and binutils-1.15. also 
assuming, only need to support older cpu and nothing new. i am guessing 
porting all the assembly files (*.s) would be sufficient?

Re: will this idea work?

[Szabolcs Nagy]

* 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
> older tools, specially gcc-3.4.5 and binutils-1.15. also assuming, only need
> 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.

Re: will this idea work?

[Po-yi Wang]

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?

Re: will this idea work?

[Rich Felker]

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?

Rich

Re: will this idea work?

[Po-yi Wang]

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
>

Re: will this idea work?

[Rich Felker]

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.

> 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

Re: will this idea work?

[Po-yi Wang]

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
>

Re: will this idea work?

[A. Wilcox]

[-- Attachment #1.1: Type: text/plain, Size: 2739 bytes --]

On 01/25/18 20:07, 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:
>>>> 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.

Though I can't really comment on speed, I will say that for the
following hardware platforms:

* x86: Pentium III 733MHz, 1 GB RAM, 100 GB PATA disk

* PPC: G3 600MHz, "Snow" iBook, 640 MB RAM, 40 GB PATA disk

I was able to build an entire Gentoo stage3 using musl + gcc 5.3 +
binutils 2.27.  This was "Foxtoo", the project before Adélie.  There was
no x86_64 builder of any kind involved, except the initial cross.  They
did however both take a few days of building without being powered off.

I will, however, agree that GCC 7 seemed to me to be a hot mess.
Haven't evaluated 7.2, but 7.1 was completely unusable for us.

Best,
--arw


-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 866 bytes --]