Uh oh!
There was an error while loading. Please reload this page.
[native-library] If a dllimport is specified with an absolute path, look for it first - #85255
Merged
Merged
Conversation
lambdageek
commented
Apr 24, 2023
MemberAuthor
ghost
commented
Apr 24, 2023
Tagging subscribers to this area: Issue DetailsThe unmanaged native library probing documentation says to try absolute paths without variations
|
rolfbjarne
approved these changes
Apr 24, 2023
Uh oh!
There was an error while loading. Please reload this page.
am11
reviewed
Apr 24, 2023
Uh oh!
There was an error while loading. Please reload this page.
…ook for it first The unmanaged native library probing documentation says to try absolute paths without variations https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing#unmanaged-native-library-probing
lambdageekforce-pushed
the
fix-native-loader-abspath
branch
from
April 24, 2023 15:38
e9f5505 to
130794dComparelambdageek
marked this pull request as ready for review
April 24, 2023 15:56
thaystg
approved these changes
Apr 24, 2023
lambdageek
commented
Apr 24, 2023
MemberAuthor
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
lambdageek
commented
Apr 24, 2023
MemberAuthor
/backport to release/7.0-staging |
Contributor
Started backporting to release/7.0-staging: https://github.com/dotnet/runtime/actions/runs/4789974115 |
lambdageek
commented
Apr 24, 2023
MemberAuthor
Verified that without this, doing [DllImport("/System/Library/Frameworks/SceneKit.framework/SceneKit")]privateexternstaticvoidSomething();will probe like this: with this PR it probes like this: |
lambdageek added a commit
to lambdageek/runtime
that referenced
this pull request
Apr 24, 2023
…ook for it first The unmanaged native library probing documentation says to try absolute paths without variations https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing#unmanaged-native-library-probing Manual backport of dotnet#85255 to net6
lambdageek
commented
Apr 24, 2023
MemberAuthor
net6 backport is #85271 |
lambdageek added a commit
that referenced
this pull request
Apr 26, 2023
…ook for it first (#85271) The unmanaged native library probing documentation says to try absolute paths without variations https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing#unmanaged-native-library-probing Manual backport of #85255 to net6
rolfbjarne added a commit
to rolfbjarne/macios
that referenced
this pull request
Apr 27, 2023
1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack.
rolfbjarne added a commit
to dotnet/macios
that referenced
this pull request
Apr 27, 2023
1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack.
rolfbjarne added a commit
to rolfbjarne/macios
that referenced
this pull request
Apr 27, 2023
…ccore@2668. 1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack. Backport of dotnet#18159.
vs-mobiletools-engineering-service2 pushed a commit
to vs-mobiletools-engineering-service2/xamarin-macios
that referenced
this pull request
Apr 27, 2023
1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack.
vs-mobiletools-engineering-service2 pushed a commit
to vs-mobiletools-engineering-service2/xamarin-macios
that referenced
this pull request
Apr 27, 2023
1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack.
rolfbjarne added a commit
to rolfbjarne/macios
that referenced
this pull request
Apr 27, 2023
1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack. This is a backport of #dotnet#18159.
rolfbjarne added a commit
to rolfbjarne/macios
that referenced
this pull request
Apr 27, 2023
…ccore@2668. 1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack. This is a backport of dotnet#18159.
rolfbjarne pushed a commit
to dotnet/macios
that referenced
this pull request
Apr 28, 2023
…ccore@2668. (#18167) 1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack. Backport of #18159
rolfbjarne added a commit
to dotnet/macios
that referenced
this pull request
Apr 28, 2023
…ccore@2668. (#18172) 1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack. Backport of #18159
rolfbjarne added a commit
to dotnet/macios
that referenced
this pull request
Apr 28, 2023
…ccore@2668. (#18171) 1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack. This is a backport of #18159.
rolfbjarne pushed a commit
to dotnet/macios
that referenced
this pull request
Apr 28, 2023
#18166) 1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack. This is a backport of #18159.
rolfbjarne added a commit
to rolfbjarne/macios
that referenced
this pull request
Apr 28, 2023
1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack. This is a backport of dotnet#18159.
vs-mobiletools-engineering-service2 pushed a commit
to vs-mobiletools-engineering-service2/xamarin-macios
that referenced
this pull request
Apr 28, 2023
1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack.
elinor-fung
commented
May 1, 2023
Member
Thank you for handling this! |
rolfbjarne pushed a commit
to dotnet/macios
that referenced
this pull request
May 3, 2023
…core@2668. (#18181) 1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack. Backport of #18159
rolfbjarne added a commit
to dotnet/macios
that referenced
this pull request
May 3, 2023
#18178) 1. Mono changed dyld lookup to start looking in directories in NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the given path is absolute [1]. 2. This turned out to break Mac Catalyst, because when a DllImport says a P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit", Mono would try loading by prefixing the directories in NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", and things would go wrong. 3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works on Ventura, but apparently not on older macOS version, because the actual path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit" (note the three initial slashes instead of a single slash). 4. Add a second workaround, where we add a dll import resolver to load exactly the path we want to load. [1]: dotnet/runtime@5a1baeb [2]: dotnet/runtime#85255 Technical sidenote: Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit" turned out so bad on Mac Catalyst is not obvious. What happens is this: * The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")' * dlopen checks if this is a Mac Catalyst override of a macOS system framework, by prefixing "/System/iOSSupport" and trying to load that. So dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit", which would obviously fail. * Then dlopen would try a few more fallbacks, eventually trying "/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully loading that library. * Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit" is the correct version). These two libraries are incompatible, and calling one when you mean to call the other will do nasty things like corrupting the stack. This is a backport of #18159.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The unmanaged native library probing documentation says to try absolute paths without variations
https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing#unmanaged-native-library-probing