https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67710
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #37060|0 |1
is obsolete| |
--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 37184
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37184&action=edit
revised fix
So this is based on Rainer's patch…
A/ Newer versions of ld64 check the min_version command, and newer versions of
the system assembler inserts this in response to "-mmacosx-version-min=" on the
assembler line.
Unless one makes sensible versions, some object is bound to conflict.
B/ Additionally, there's a difference in behaviour between "as" and "ld" when
presented with xx.yy.zz (ld truncates to xx.yy, as doesn't); net result is that
one needs to pass a truncated version to "as".
So (if the assembler supports minversion commands)
(a) provide a truncated minversion (as asm_macosx_version_min, which is a
driver-only var).
(b) pass this to "as"
(c) Update tests to determine 'HAVE_AS_MMACOSX_VERSION_MIN_OPTION' (Rainer's
patch)
(d) For some reason the testcases are "run" (it's not obvious they need to be,
they are checking compile-time issues)
- anyway, to preserve the status quo, I've left them as exec. However, the
minimum version that can be code-gened for is target-dependent (there are no
x86 versions before 10.4, for example). To avoid conflicts where the "as" is
assuming some minimum, I've set the testversion to 10.5 (which is supported by
all the archs we have)
(e) We need to ensure that libgcc and crts are generated with a sufficiently
old minversion not to conflict.
Works For Me(™) on 10.10 with XC7.2 and 10.8.5 with XC5.1.1
