https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123841
--- 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). > >> My current idea is to ultimately have four patches: > >> > >> * One patch that ensures that gas_flag/gnu_ld_flag are always set and > >> match the assembler and linker used (gcc_cv_as/gcc_cv_ld). > >> > >> * The next is a revised version of the attached one: it handles > >> Darwin/as and Solaris/as separately and applies gas options > >> (--32/--64/--x32) on all x86 *and sparc* targets that have been > >> determined to use gas. > > > > The concern that I have is that Darwin versions that use “cctools” report > > that the assembler is “GNU assembler" (1.38). However, when I last looked > > the assumptions that configure makes for “assembler == gas” are not > > suitable for the ancient version on which cctools is based; so IIRC we have > > logic to ensure that darwin's "GNU assembler" is _not_ recognised as GAS > > I'd think we need to keep that in mind. > > 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". > * gas-compatible assembler syntax > > The syntax part at least is necessary for the compiler proper, too, > usually controlled by HAVE_GNU_AS. Even if the syntax is (largely) > compatible, HAVE_GNU_AS is sometimes used to distinguish between the > real gas (or an assembler that's completely compatible) and assemblers > that have some quirks relative to that. > > It doesn't really matter if the assembler *is* (as in identifies as gas) > here. > > 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. 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 agree that there's no realistic (usable) binutils assembler for Darwin (I > > did > > 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).
