Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
rpath problem with librocksdb on macOS #182
I've got RocksDB installed via MacPorts in
I can fix that by setting
Likely you could also correct the install_name directly in the librocksdb.dylib:
At least that's sufficient for me when when reproducing the problem via building rocksdb from source and installing to a non-standard path.
Makes me think this is more of an upstream problem. I expect the various build systems (autotools, cmake, etc.) usually have standard ways of setting the install_name for .dylibs, but rocksdb just has a basic Makefile that does things manually. This would be a guess at an upstream patch that sets the install_name to the correct absolute path:
diff --git a/Makefile b/Makefile index db6099b67..f1fe65b94 100644 --- a/Makefile +++ b/Makefile @@ -1546,6 +1546,9 @@ install-shared: install-headers $(SHARED4) ln -fs $(SHARED4) $(INSTALL_PATH)/lib/$(SHARED3) && \ ln -fs $(SHARED4) $(INSTALL_PATH)/lib/$(SHARED2) && \ ln -fs $(SHARED4) $(INSTALL_PATH)/lib/$(SHARED1) +ifeq ($(PLATFORM), OS_MACOSX) + install_name_tool -id $(INSTALL_PATH)/lib/$(SHARED4) $(INSTALL_PATH)/lib/$(SHARED4) +endif # install static by default + install shared if it exists install: install-static
Or else it could be something for the MacPorts package maintainer to improve. As a reference, the Homebrew package for rocksdb uses an absolute path for the .dylib's install_name and works fine. Also curious that your
I'd say this can be closed, unless there's ideas on how to handle it ourselves.
Yeah, I can see that. The only thing that struck me is that librocksdb.5.14.dylib stands out in the otool output in that it has neither an absolute path nor an @rpath. Is that something controlled on our end, or is that information pulled in from the installed library?
It's the name rocksdb picked for itself at link-time via the
If you build/install current rocksdb from source you get:
And linking against that reproduces the Bro linking issue:
After patching rocksdb to name it via absolute path:
And Bro is happy:
Here's what Homebrew has:
And Bro works with that, no changes needed.
So that's all why I think an action in either rocksdb or MacPorts is appropriate . Maybe try asking MacPorts first and see if they want to take it further upstream to rocksdb ?