You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, doing otool -L on the native library gives us this output:
otool -L libgit2-15e1193.dylib
libgit2-15e1193.dylib:
/Users/travis/build/libgit2/libgit2sharp.nativebinaries/libgit2/build/libgit2-15e1193.26.dylib (compatibility version 26.0.0, current version 0.26.0)
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 8.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57337.40.83)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1258.1.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
That means that the library will fail to resolve if it's copied to the output directory without special DYLD_* env vars.
Stripping the path at build time or using @loader_path (CMAKE_INSTALL_RPATH @loader_path) would fix this or post-build with install_name_tool -id would allow the library to be used out of the box on Mono on OS X.
The text was updated successfully, but these errors were encountered:
The current native binaries package puts the binaries in a known location and uses a dllmap to point to the file.
Given that this is the default scenario that the packages are set up to support, I assume you're talking about some other scenario here? Can you explain what you'd be doing where relying on the package defaults wouldn't be enough?
Yeah, it seems like the dllmap scenario is good enough for the mono loader. I misjudged some initial results in some code which ended up making me think it was a native library resolution issue rather than a use-after-dispose-crash-in-native. Issue can be closed.
Thanks for clarifying @Therzok. I do still think that it's worth stripping our build path out of the library. (There's no reason for it to be there.) But I don't think it's critical.
Currently, doing
otool -L
on the native library gives us this output:That means that the library will fail to resolve if it's copied to the output directory without special DYLD_* env vars.
Stripping the path at build time or using
@loader_path
(CMAKE_INSTALL_RPATH @loader_path
) would fix this or post-build withinstall_name_tool -id
would allow the library to be used out of the box on Mono on OS X.The text was updated successfully, but these errors were encountered: