<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><blockquote type="cite"><pre><br></pre><pre>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? </pre></blockquote><div><br></div>it means that gcc would use /usr/bin/as as the default assembler going forward for everything it builds, unless forced to do otherwise. This is suboptimal, because /usr/bin/as is very old, and much breakage is to be expected with such a plan. <div><div><br></div><div><a href="https://gcc.gnu.org/install/configure.html">https://gcc.gnu.org/install/configure.html</a></div><div><br></div><div><blockquote type="cite"><pre>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.</pre></blockquote><div>Hah. Looking forward to the fix :> We've been trying for almost a year without success, but I welcome the missing configure flag, should it exist!</div></div><div><br></div><div>If might be fixable if gcc would obey environment variables during it's build of libgcc by the stage1 compiler. It doesn't seem to, no doubt to prevent unexpected wreckage.</div><div><br></div><blockquote type="cite"><pre>On Fri, 6 Mar 2020, Ken Cunningham wrote:
><i> I am discussing with the gcc darwin lead to see if any other options are
</i>><i> available.
</i>
Maybe that will help.
</pre></blockquote><div><br></div>It's not easy for me to bug Iain with low-level crap like this that we created ourselves. He has plenty enough to do...but luckily for us he is a surprisingly agreeable compiler authour !<div><br></div><div>Ken</div><div><br></div><div><br><div><br></div></div></div></body></html>