NativeAOT result binary on macOS targets latest SDK #98124

Activity

1. ghost added

   needs-area-labelAn area label is needed to ensure this gets routed to the appropriate area ownersAn area label is needed to ensure this gets routed to the appropriate area owners

   on Feb 7, 2024
2. ghost added

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Feb 7, 2024
3. mklts

   changed the title [-]NativeAOT result binary on macos targets latest SDK[/-] [+]NativeAOT result binary on macOS targets latest SDK[/+] on Feb 7, 2024
4. vitek-karas

   added

   area-NativeAOT-coreclr

   on Feb 7, 2024
5. github-project-automation

   added this to AppModelon Feb 7, 2024
7. filipnavara

   removed

   needs-area-labelAn area label is needed to ensure this gets routed to the appropriate area ownersAn area label is needed to ensure this gets routed to the appropriate area owners

   on Feb 7, 2024
8. MichalStrehovsky

   added

   os-macosmacOS aka OSXmacOS aka OSX

   on Feb 8, 2024
9. filipnavara commented on Feb 8, 2024

   

   filipnavara

   on Feb 8, 2024

   Last edited by filipnavara

   Member

   More actions

   It seems that the logic in the build files only covers iOS-like platforms. We should probably fix that.

   As a workaround you can add an argument to the linker in the .csproj file:

       <ItemGroup>
         <LinkerArg Include="-mmacosx-version-min=11.0" />
       </ItemGroup>
   

   ❤️React with ❤️1Reacted by Sergey Mikolaitis
10. ghost added

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Feb 9, 2024
11. jkotas

    closed this as completedin #98233on Feb 10, 2024
12. ghost removed

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Feb 10, 2024
13. ghost removed

    untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

    on Feb 10, 2024
14. jkotas commented on Feb 10, 2024

    

    jkotas

    on Feb 10, 2024

    Member

    More actions

    Trying to determine whether this warrants a backport. What is this version used for? Does macOS block binaries with minos version 14.0 from being launched on older macOS versions?
15. filipnavara commented on Feb 10, 2024

    

    filipnavara

    on Feb 10, 2024

    Member

    More actions

    Yes, older macOS versions would block running the binaries. I am leaning towards doing a backport. Xamarin workloads already do this and so this is unexpected inconsistency between net8.0 and net8.0-macos. On the other hand the workaround is pretty easy.

    I can open a PR when I get home and we can either proceed with it or close it.
16. filipnavara commented on Feb 10, 2024

    

    filipnavara

    on Feb 10, 2024

    Member

    More actions

    I made the backport - https://github.com/dotnet/runtime/compare/release/8.0-staging...filipnavara:runtime:min-version-80?expand=1 - and started filling the template, only to realize that macOS (14.3.1) actually ignores the value for console applications, and so does the linker when referencing a dynamic library. With that in mind I no longer think the backport is necessary.

    In case the opinion changes in the future, here's part of the prefilled template:

    Backport of #98233
    
    /cc @jkotas
    
    ## Customer Impact
    
    - [x] Customer reported
    - [ ] Found internally
    
    Reported in #98124. Applications and shared libraries targeting `net8.0` without the macOS workload (ie. `net8.0-macos` is not affected) get indeterministic minimum OS version number in the executable header when compiled. Instead of getting the minimum macOS version supported by .NET 8.0, which is macOS 11.0, they get the version corresponding to the Xcode SDK installed on the build machine.
    
    The OS itself seems to ignore the version number for executables (as of macOS 14.3.1), and so does the linker when linking against a dynamic library compiled with NativeAOT. 
    
    ## Regression
    
    - [ ] Yes
    - [x] No
    
    .NET 8 was the first version of .NET to support NativeAOT on macOS.
    
    ## Testing
    
    The fix was tested by compiling a NativeAOT application on macOS with `dotnet publish -p:PublishAot=true` and then verifying the version headers of the exectuable with `vtool -show <path to output binary>`.
    
    ## Risk
    
    Low. [To be filled]
    

    👍React with 👍1Reacted by Jan Kotas
17. jkotas commented on Feb 11, 2024

    

    jkotas

    on Feb 11, 2024

    Member

    More actions

    @filipnavara Thank you for looking into it!
18. github-actions

    locked and limited conversation to collaborators on Mar 12, 2024