gcc won't build i386 with our cctools assembler hack

[Fred Wright]

On Wed, 4 Mar 2020, Ken Cunningham wrote:
>> On Tue, 25 Feb 2020, Ken Cunningham wrote:
>>
>>> building i386, gcc 5,6,7,8 misconfigures when our "as" redirects it to
>>> clang for assembly, following our hack in cctools to do that. the gcc
>>> build then fails.
>>>
>>> I have not so far been able to overcome this other than:
>>>
>>> 1. deactivating all clangs 5+ prior to the build, to get the old gas
>>>
>>> or
>>>
>>> 2. defaulting gcc to use --with-as=/usr/bin/as
>>>
>>> Having the built gcc forever use /usr/bin/as as assembler would be
>>> awful, so option 1 looks better than 2. but ugh.
>>>
>>> I tried many things. gcc is complicated to build when you want it to do
>>> non-standard stuff. There may be some way to make it work...pls chime
>>> in...but I have likely tried it.
>>
>> You don't make it clear whether this is solely about building gcc itself,
>> or about building things *with* gcc.
>
> building gcc itself. I assume you have tried recently. It's been broken 
> since the cctools assembler hack went in, AFAICT.

Yes and no.  My only i386 "machine" is my 10.5 VM, which currently has a 
bunch of other broken ports.  Except for that, I only build i386 when it's 
universal, which tends to be an enormous rabbit hole in may cases.

>> The "forever" might just be "until there's a better solution", and it's
>> hard to see how option 2 would be more awful than creating yet another "X
>> can't build while Y is active" abomination.
>
> If we build gcc to default to use /usr/bin/as then all those i386's are 
> forever sent to that truly ancient assembler. That is pretty awful -- 
> who knows how many things will break doing that. It won't even accept 
> the -Q flag.

I'm puzzled.  If this is solely about building gcc itself, doesn't that 
mean that the iuse of /usr/bin/as is only inflicted on gcc itself?  Or is 
it something that would propagate to its targets?  If so, does the gcc 
bootstrap process include building gas, and if so, could it be hacked to 
use /usr/bin/as to build gas and then gas for the real build?

If the concern is just for future gcc versions, then that could be in the 
"cross that bridge when we come to it" category.

I don't know what this "cctools assembler hack is", but if that's breaking 
the gcc build, it should probably be fixed not to.  It's best if all ports 
are fully Hippocratic ("first do no harm").

> At least if we conflicts-build it, once it is built (a minor 
> inconvenience for the systems we're talking about, (10.4 i386, 10.5 
> i386, and 10.6 i386), it will use /opt/local/bin/as, which is current, 
> and also can redirect to clang for fancier assemblage (that usually 
> works still).

Unless precompiled binaries are offered for all variants, "once it is 
built" will often be per-user in practice.  It's getting to the point 
where "upgrade outdated" needs an AI front end.

> Fred, you might have built gcc once or twice I suspect.

More than I'd like to have. :-) Especially on slow machines.  The last 
upgrade of gcc7 on the PowerBook took about 15 hours.

> Give an i386 build a try and see if you can come up with something. I 
> don't love this plan either.

On Fri, 6 Mar 2020, Ken Cunningham wrote:

> I am discussing with the gcc darwin lead to see if any other options are 
> available.

Maybe that will help.

Fred Wright