Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider RPATH-ing native library name on OS X #55

Closed
Therzok opened this issue Jul 24, 2017 · 3 comments
Closed

Consider RPATH-ing native library name on OS X #55

Therzok opened this issue Jul 24, 2017 · 3 comments

Comments

@Therzok
Copy link
Member

Therzok commented Jul 24, 2017

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.

@bording
Copy link
Member

bording commented Jul 24, 2017

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?

@Therzok
Copy link
Member Author

Therzok commented Jul 24, 2017

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.

@Therzok Therzok closed this as completed Jul 24, 2017
@ethomson
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants