Re: [PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))
Hi Simon,
> On 11 Jun 2022, at 20:23, Simon Wright wrote:
>
> On 11 Jun 2022, at 11:37, Iain Sandoe wrote:
>>
>> Hi Simon,
>>
>> thanks for the patch.
>>
>>> On 11 Jun 2022, at 10:17, Simon Wright wrote:
>>>
>>> (resent with correct address for Iain)
>>>
>>> This is the same sort of problem as in PR80204: at present, GCC 11 & 12
>>> assume that if the
>>> OS version is >= 20, the compiler should see --mmacosx-version-min={major -
>>> 9}.{minor -1}.0,
>>> e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees
>>> -macosx-version-min, same
>>> arguments).
>>>
>>> However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler
>>> sees
>>> -triple x86_64-apple-macosx12.0.0
>>> and the linker sees
>>> -platform_version macos 12.0.0
>>> the result of which is that linking an object file built with clang and one
>>> built with gcc gives e.g.
>>>
>>> ld: warning: object file (null.o) was built for newer macOS version (12.2)
>>> than being linked (12.0)
>>>
>>> I propose the following patch, which works fine for me (darwin 21.3.0).
>>
>> this LGTM - just need to sort out a couple of nits and an admin point.
>>
>> FWIW; the following are honoured in preserving the minor version (so we
>> still have scope for
>> mismatches if some objects are built this way and others picking up the
>> kernel version) ..
>>
>> clang -target x86_64-apple-macosx11.3 …
>> clang -mmacosx-version-min=11.3 …
>> MACOSX_DEPLOYMENT_TARGET=11.3 clang … (although this seems on at least one
>> version
>> of xcodem to pass 12.3 to the linker.. hmmm).
>
> Something on the lines of "the native compiler clang treats 21.3.0 as 12.0.0
> (unless overridden by e.g.
> MACOSX_DEPLOYMENT_TARGET=11.3 )"?
>
> I did see in the otool -l report on a gcc 12.1.0 executable generated as
> above (Darwin 21.5.0)
>
> cmd LC_BUILD_VERSION
> cmdsize 32
> platform 1
> minos 11.3
> sdk 10.17
>
> — don’t know where the 10.17 comes from,
That’s the version of the SDK in use (it’s embedded in the plist of the SDK
except in the very early ones).
The full -platform_version command has a space for the SDK, perhaps ld64 looks
it up these days if not
supplied on the command line. Odd that it’s named 10.17 instead of 11.x
(the latest sources for ld64 are quite old now, so can’t check what newer
versions of the linker are doing).
> still there even without MACOSX_DEPLOYMENT_TARGET.
> The SDK was Xcode 13.4.1. I also have CLT 13.4.0.0.1.1651278267. clang tells
> ld
> "-platform_version macos 11.3.0 12.3", gcc just says "-macosx_version_min
> 11.3".
GCC does not implement the -platform_version command yet (we have a configure
scan for it but
not needed to use it so far) - not sure if we really want to get into parsing
plist files to find the SDK version
(or get tied to using more tools out of our control).
>> I guess you do not have commit access?
>> if you do not have an FSF assignment for copyright, are you OK to sign this
>> off using the DCO?
>>
>> https://gcc.gnu.org/dco.html
>
> No commit access, but FSF assignment RT:1016382. Do I need to say this in the
> patch email somewhere?
no, that’s fine - we just need one (assignment) or the other (DCO).
>> for furture reference, please check that patches conform to GCC coding style
>> (this one has some
>> whitespace glitches)
>
> I don’t see the whitespace glitches? (I have missed a period after ld in the
> second comment)
sets of 8 leading spaces should be tabs.
the source tree has some checking tools for commits (in contrib/ ), which can
be useful.
It’s also quite handy to have the entire commit with the commit message in
one’s local repo and then
just do “git format-patch -1 xxx” to get the patch for posting (but, of
course, everyone has
their own favourite git workflow).
OK, thanks, I think I’ve got everything needed to get this applied, there’s no
need to re-issue, I’ll tweak
the commit message and the whitespace.
Iain
>
>>
>> thanks,
>> Iain
>>
>>
>>> gcc/ChangeLog:
>>>
>>> 2022-06-02 Simon Wright
>>>
>>> PR target/104871
>>> * config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS
>>> version is
>>> 20 (macOS 11) or greater, report the minor version and the patch level as 0
>>> to match Apple clang’s behaviour.
>>>
>>>
Re: [PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))
On 11 Jun 2022, at 11:37, Iain Sandoe wrote:
>
> Hi Simon,
>
> thanks for the patch.
>
>> On 11 Jun 2022, at 10:17, Simon Wright wrote:
>>
>> (resent with correct address for Iain)
>>
>> This is the same sort of problem as in PR80204: at present, GCC 11 & 12
>> assume that if the
>> OS version is >= 20, the compiler should see --mmacosx-version-min={major -
>> 9}.{minor -1}.0,
>> e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees
>> -macosx-version-min, same
>> arguments).
>>
>> However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
>> -triple x86_64-apple-macosx12.0.0
>> and the linker sees
>> -platform_version macos 12.0.0
>> the result of which is that linking an object file built with clang and one
>> built with gcc gives e.g.
>>
>> ld: warning: object file (null.o) was built for newer macOS version (12.2)
>> than being linked (12.0)
>>
>> I propose the following patch, which works fine for me (darwin 21.3.0).
>
> this LGTM - just need to sort out a couple of nits and an admin point.
>
> FWIW; the following are honoured in preserving the minor version (so we still
> have scope for
> mismatches if some objects are built this way and others picking up the
> kernel version) ..
>
> clang -target x86_64-apple-macosx11.3 …
> clang -mmacosx-version-min=11.3 …
> MACOSX_DEPLOYMENT_TARGET=11.3 clang … (although this seems on at least one
> version
> of xcodem to pass 12.3 to the linker.. hmmm).
Something on the lines of "the native compiler clang treats 21.3.0 as 12.0.0
(unless overridden by e.g.
MACOSX_DEPLOYMENT_TARGET=11.3 )"?
I did see in the otool -l report on a gcc 12.1.0 executable generated as above
(Darwin 21.5.0)
cmd LC_BUILD_VERSION
cmdsize 32
platform 1
minos 11.3
sdk 10.17
— don’t know where the 10.17 comes from, still there even without
MACOSX_DEPLOYMENT_TARGET.
The SDK was Xcode 13.4.1. I also have CLT 13.4.0.0.1.1651278267. clang tells ld
"-platform_version macos 11.3.0 12.3", gcc just says "-macosx_version_min 11.3".
> I guess you do not have commit access?
> if you do not have an FSF assignment for copyright, are you OK to sign this
> off using the DCO?
>
> https://gcc.gnu.org/dco.html
No commit access, but FSF assignment RT:1016382. Do I need to say this in the
patch email somewhere?
> for furture reference, please check that patches conform to GCC coding style
> (this one has some
> whitespace glitches)
I don’t see the whitespace glitches? (I have missed a period after ld in the
second comment)
>
> thanks,
> Iain
>
>
>> gcc/ChangeLog:
>>
>> 2022-06-02 Simon Wright mailto:si...@pushface.org>>
>>
>> PR target/104871
>> * config/darwin-driver.cc
Re: [PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))
Hi Simon,
thanks for the patch.
> On 11 Jun 2022, at 10:17, Simon Wright wrote:
>
> (resent with correct address for Iain)
>
> This is the same sort of problem as in PR80204: at present, GCC 11 & 12
> assume that if the
> OS version is >= 20, the compiler should see --mmacosx-version-min={major -
> 9}.{minor -1}.0,
> e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees
> -macosx-version-min, same
> arguments).
>
> However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
> -triple x86_64-apple-macosx12.0.0
> and the linker sees
> -platform_version macos 12.0.0
> the result of which is that linking an object file built with clang and one
> built with gcc gives e.g.
>
> ld: warning: object file (null.o) was built for newer macOS version (12.2)
> than being linked (12.0)
>
> I propose the following patch, which works fine for me (darwin 21.3.0).
this LGTM - just need to sort out a couple of nits and an admin point.
FWIW; the following are honoured in preserving the minor version (so we still
have scope for
mismatches if some objects are built this way and others picking up the kernel
version) ..
clang -target x86_64-apple-macosx11.3 …
clang -mmacosx-version-min=11.3 …
MACOSX_DEPLOYMENT_TARGET=11.3 clang … (although this seems on at least one
version
of xcodem to pass 12.3 to the linker.. hmmm).
I guess you do not have commit access?
if you do not have an FSF assignment for copyright, are you OK to sign this off
using the DCO?
https://gcc.gnu.org/dco.html
for furture reference, please check that patches conform to GCC coding style
(this one has some
whitespace glitches)
thanks,
Iain
> gcc/ChangeLog:
>
> 2022-06-02 Simon Wright
>
> PR target/104871
> * config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS
> version is
> 20 (macOS 11) or greater, report the minor version and the patch
> level as 0
> to match Apple clang’s behaviour.
>
>
[PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))
(resent with correct address for Iain)
This is the same sort of problem as in PR80204: at present, GCC 11 & 12 assume
that if the
OS version is >= 20, the compiler should see --mmacosx-version-min={major -
9}.{minor -1}.0,
e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees
-macosx-version-min, same
arguments).
However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
-triple x86_64-apple-macosx12.0.0
and the linker sees
-platform_version macos 12.0.0
the result of which is that linking an object file built with clang and one
built with gcc gives e.g.
ld: warning: object file (null.o) was built for newer macOS version (12.2)
than being linked (12.0)
I propose the following patch, which works fine for me (darwin 21.3.0).
gcc/ChangeLog:
2022-06-02 Simon Wright
PR target/104871
* config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS
version is
20 (macOS 11) or greater, report the minor version and the patch
level as 0
to match Apple clang’s behaviour.
pr104871.diff
Description: Binary data
[PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))
(resent with commit message format update)
This is the same sort of problem as in PR80204: at present, GCC 11 & 12 assume
that if the
OS version is >= 20, the compiler should see --mmacosx-version-min={major -
9}.{minor -1}.0,
e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees
-macosx-version-min, same
arguments).
However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
-triple x86_64-apple-macosx12.0.0
and the linker sees
-platform_version macos 12.0.0
the result of which is that linking an object file built with clang and one
built with gcc gives e.g.
ld: warning: object file (null.o) was built for newer macOS version (12.2)
than being linked (12.0)
I propose the following patch, which works fine for me (darwin 21.3.0).
gcc/ChangeLog:
2022-06-02 Simon Wright
PR target/104871
* config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS
version is
20 (macOS 11) or greater, report the minor version and the patch
level as 0
to match Apple clang’s behaviour.
pr104871.diff
Description: Binary data
[PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))
This is the same sort of problem as in PR80204: at present, GCC 11 & 12 assume
that if the
OS version is >= 20, the compiler should see --mmacosx-version-min={major -
9}.{minor -1}.0,
e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees
-macosx-version-min, same
arguments).
However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
-triple x86_64-apple-macosx12.0.0
and the linker sees
-platform_version macos 12.0.0
the result of which is that linking an object file built with clang and one
built with gcc gives e.g.
ld: warning: object file (null.o) was built for newer macOS version (12.2)
than being linked (12.0)
I propose the following patch, which works fine for me (darwin 21.3.0).
gcc/ChangeLog:
2022-06-02 Simon Wright
PR target/104871
* config/darwin-driver.cc (darwin_find_version_from_kernel): if the OS
version is
20 (macOS 11) or greater, report the minor version and the patch
level as 0
to match Apple clang’s behaviour.
pr104871.diff
Description: Binary data
