Skip to content

Conversation

@Clement-Cardot
Copy link

Hi there,

Is it normal that this value is not the same as the ROCKSDB_LIBRARY_NAME in NativeLibraryLoader.java ?
This cause an error if you try to load the .so manually and then load RockDB, see example below :

String customDir = "/custom/path/";
NativeLibraryLoader.getInstance().loadLibrary(customDir);
RocksDB.loadLibrary(customDir);
  • The NativeLibraryLoader.getInstance().loadLibrary(customDir) will load a file named librocksdbjni-linux64.so
  • But the RocksDB.loadLibrary(customDir) will try to find librocksdbjnijni-linux64.so (NB: jnijni)

I assume it's not on purpose but let me now if there is a good reason for that !

And if you want to know why I need to load the .so manually :
On securized linux environnement, the /tmp does not allow to dynamically link libs (see this message for more info : docker-flink/docker-flink#46 (comment))
As I can't neither change that or change the java.io.tmpdir to an other path (because I want the rest of my temporary files to stay in the /tmp dir). I'm forced to load the .so manually.

Also I now that I could use the ROCKSDB_SHAREDLIB_DIR environnement variable, but I don't want that my code depends on environments values (for many reasons)

Edit: I find out that by calling RocksDB.loadLibrary() without the path, the function find out that the lib has already been loaded thanks to the "initialized" variable in the NativeLibraryLoader class.

String customDir = "/custom/path/";
NativeLibraryLoader.getInstance().loadLibrary(customDir);
RocksDB.loadLibrary();

@meta-cla
Copy link

meta-cla bot commented Dec 3, 2025

Hi @Clement-Cardot!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

@Clement-Cardot Clement-Cardot changed the title fix: match with NativeLibraryLoader ROCKSDB_LIBRARY_NAME value fix: lib name match with NativeLibraryLoader ROCKSDB_LIBRARY_NAME value Dec 3, 2025
@meta-cla
Copy link

meta-cla bot commented Dec 3, 2025

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

@meta-cla meta-cla bot added the CLA Signed label Dec 3, 2025
@adamretter
Copy link
Contributor

@Clement-Cardot Thanks for the PR and comments, let me take a look into this and come back to you...

@Clement-Cardot
Copy link
Author

Clement-Cardot commented Dec 3, 2025

Thanks @adamretter

Btw, I just figured out that i don't even need to call RocksDB.loadLibrary()
So no real "bug".
But i think it is still a typo issue :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants