search

libgit2 / libgit2sharp.nativebinaries

MIT License
28 stars 62 forks source link

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

Closed Therzok closed 7 years ago

Therzok commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

ethomson commented 7 years ago

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.