https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123841
--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #36 from Iain Sandoe <iains at gcc dot gnu.org> --- > (In reply to [email protected] from comment #35) >> > --- Comment #34 from Iain Sandoe <iains at gcc dot gnu.org> --- >> > (In reply to [email protected] from comment #31) >> >> > --- Comment #27 from Rainer Orth <ro at gcc dot gnu.org> --- > > The first posted patch has succeeded in bootstrap of i686 and powerpc > darwin9 (so OK from Darwin PoV). Good, thanks for confirming. In my updated patch I've just added a comment about the cctools vs. clang versions of as. >> I've been wondering myself, however from a different direction >> initially. gcc/configure needs to know about two things: >> >> * gas-compatible command line options rather than vendor assembler ones. >> The latter are probably rare: Solaris as, Darwin as, and maybe HP-UX. > > Right - I think my only point is that Darwin as should always be considered > "vendor" even when it identifies as "GNU assembler 1.38". Exactly what the initial version of the patch had done; I now keep doing this on Darwin even if the assembler identifies as gas. >> As for the Darwin case, I've just looked at the earliest cctools release >> I could find: cctools-358 from >> https://github.com/apple-oss-distributions/cctools. This one identifes >> as GNU assembler version 1.38 as you said, but at least understands >> -arch just like the later clang-based assemblers. So I thing we should >> keep using *-*-darwin*:* in acinclude.m4 since the assembler's >> self-identifications changes nothing both for options and assembler >> syntax. > > Yes, FAOD modern GCC will not build on any earlier Darwin system without > updating 'cctools' and 'ld64' to at least the versions from Xcode-3.1.4 > (which was the version for Darwin9 / macOS 10.5). This is because of > facilities needed by C++. (so there is no need to consider anything more > ancient). All relevant versions support (require, even) the `-arch` flag. I see. So far I've been lucky enough to be able and make do with the bundled versions of as. I'd run bootstraps on 10.7 for quite some time, but now restrict myself to 10.13 (for 32/64-bit-default builds), 12, and 26, all in Qemu VMs because VirtualBox cannot handle anything beyond 12 and is often quite unreliable on earlier versions. > To complete the record, D will not build with a version of ld64 < 97.x > (which was the version from Darwin10 / macOS 10.6) .. I use a set of tools > based on a later version of ld64 and cctools to support testing "all > languages" > on earlier OS versions (Darwin9 .. Darwin12 - macOS 10.5 .. 10.8). I *think* I'd encountered the D issue on 10.7, but am too lazy to check now :-) >> > have a version that worked for x86 and ppc based on 2.21(?) but it's too >> > much >> > for me to maintain the mach-o parts of gas and bad and was abandoned in >> > favour >> > of using the LLVM backend which already has mach-o support). >> > >> > So, I'd say that we probably need to ensure that the cctools "gas" is not >> > considered to be gas - but some custom assembler for the system (likewise >> > any >> > based off various LLVM backends). >> >> Right: I'll revert the *-*-darwin*:no change from my second patch, keeping >> *-*-darwin*:* with an explanation why that's the case. > > I suppose we might consider that some brave soul could try to do a complete > binutils port for all the active archs, in which case they'd need a mechanism > to override and force the configure to GAS mode (but they'd also need to do > quite some work with the specs &c. so perhaps that's a small issue). I guess the only brave soul doing this would be yourself, though :-) And indeed, there's certainly more work to be done to accomodate such a port of current binutils, as can be seen in similar code to support both as and gas on Solaris (and HP-UX, too).
