https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123841
--- Comment #35 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- 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> --- > >> 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. * 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. > 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.
