gcc won't build i386 with our cctools assembler hack

[Ken Cunningham]

> 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.

> 
> 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.

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).


> 
> Fred Wright



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

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

K


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200304/40f4248c/attachment.html>