https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101616
--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Matt Jacobson from comment #3) > As it happens, I'm targeting the NeXT v2 runtime, but I'm *not* actually > targeting Darwin. So `flag_next_runtime` is just 1 for me--not an OS > version value like 100600 (`USE_FIXUP_BEFORE` / SnowLeopard). (And I can't > fake it via arguments, AFAICT.) As I am sure you are aware - there is quite an amount of Mach-O-specific stuff baked into the NeXT implementation. However, for any system that supports named sections it would seem reasonable to be able to support it. Perhaps raise an 'emhancement' bug "Support NeXT runtime on system xxxxx" where xxxxx is the system you want to support. There are surely a number of changes that would be needed - and some that I've most likely already thought about already (e.g. when thinking about what would be needed to support ELF-based systems). > I wonder if it would be reasonable to add a separate flag to disable (or > enable) fixup messages, such that the default value of the flag is > controlled by `-mmacosx-version-min` when targeting Darwin. Darwin does three things - (a) for an invocation without 'mmacosx-version-min' it figures out the OS version from the kernel. (b) when the invocation includes mmacosx-version-min that overrides (c) MACOSX_DEPLOYMENT_TARGET is also consulted to determine the target version if there is no mmacosx-version-min. The fine detail is that the *actual* code-gen produced by clang varies (in a way that is incompatible with various versions of the linker) - so that we have to take account of this and make sure we emit a suitable version for the OS revision being targeted. There are enough bits spare in the int representing flag_next_runtime that we could arrange to have it indicate a non-Darwin implementation in some MSBs (and then have the LSBs represent something different). I suspect that this is just one of several changes that will be needed to code-gen (thus the suggestion to have a tracking PR) and we should not be adding more flags, but rather arranging to control the value of the next_runtime flag and use that to determine the code-gen we want.
