Fix native library loading for osx-arm64#17365
Conversation
src/System.Management.Automation/CoreCLR/CorePsAssemblyLoadContext.cs
Outdated
Show resolved
Hide resolved
50e9abc to
e892dd2
Compare
|
This PR has Quantification details
Why proper sizing of changes matters
Optimal pull request sizes drive a better predictable PR flow as they strike a
What can I do to optimize my changes
How to interpret the change counts in git diff output
Was this comment helpful? 👍 :ok_hand: :thumbsdown: (Email) |
|
@SteveL-MSFT we've confirmed that the fix does work for us, but we also noticed something quite annoying that wasn't so obvious: to get automatic library loading in .NET, you have to use just the library name without the "lib" prefix and file extension. However, .NET normally expects to find "libname.dylib" on macOS, "libname.so" on Linux, and "name.dll" for pinvoke on library "name", while PowerShell apparently always assumes prefix-less library names ("name.dylib", "name.so", "name.dll"). Taking a second look at that comment block, I can see that all library names don't use the lib prefix, so I guess it's documented, but none of us had understood it was probably intentional. In any case, the fix does work for us, we can correctly load both osx-x64 and osx-arm64 native libraries. Now the real question is: do we wait until this makes it into the next PowerShell release, and when would that likely be? I'm trying to judge if we still need a temporary workaround, or if we can tell our customers to wait until the next PowerShell release for Apple M1 support. |
|
@SteveL-MSFT we've found a temporary workaround that works: putting a universal library into the osx-x64 folder. This should be good enough until the next PowerShell release containing the fix, after which we could use single-architecture libraries in their respective folders instead |
|
@awakecoding this will probably not make it into this month's preview release, but should make it into June. |
|
/azp run powershell-ci-macos |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days. |
|
@TravisEz13 Friendly ping. |
|
This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days. |
|
/backport to release/v7.2.5 |
|
Started backporting to release/v7.2.5: https://github.com/PowerShell/PowerShell/actions/runs/2456295092
|
|
🎉 Handy links: |
PR Summary
The current native library loader on macOS is hardcoded to use "osx-x64", which breaks loading native libraries under the "osx-arm64" directory.
PR Context
We've been fighting for days trying to figure out why PowerShell wouldn't load our arm64 native libraries for our PowerShell module on macOS. The reason why was quite obvious when looking at the source code.
Rather than hardcode "osx-x64" we should just use "osx-" + the process architecture like for other platforms. This is a really simple fix.