-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
Hide private symbols in shared library #12944
base: main
Are you sure you want to change the base?
Conversation
I tested this in https://salsa.debian.org/debian/rocksdb/-/merge_requests/3 and it didn't work. I wonder did I enable the flag and 'Release mode' correctly?
|
More info on how Debian scans the ABI: |
Hello @ottok, thanks for quick reply. I think we need to update CMake parameters. This is what I found in your build system : cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DWITH_BZ2=ON -DWITH_LZ4=ON -DWITH_ZLIB=ON -DWITH_ZSTD=ON -DWITH_SNAPPY=ON -DROCKSDB_BUILD_SHARED=ON -DWITH_BENCHMARK_TOOLS=ON -DWITH_CORE_TOOLS=ON -DWITH_TOOLS=ON -DWITH_TESTS=ON -DPORTABLE=1 -DHIDE_PRIVATE_SYMBOLS=1 -DFAIL_ON_WARNINGS=OFF .. I think the problem is Radek |
I applied
Seems now that the linker still sees the private symbols and fails to compute as they have become hidden..? |
Hello @ottok, thanks for quick reply. It looks like this will be bigger problem. As you suggested I hide all symbols except C API. But as you can see, other program are using also C++ API. I don't know how to efficiently export only the public symbols and hide others. I'm able to compile I think this will need more refactoring across RocksDB codebase to define which classes/structs/methods are public API and what is private. cc: @adamretter: What are your thoughts? Radek |
Thanks for looking into this and considering refactoring!
RocksDB does not strictly require this, but it would be good engineering
practice to have clear separation of private and public symbols as it
decreases the chance of bugs and makes long-term maintenance and upgrades
of the library easier and less likely to have unexpected breakage with
consuming software. Both Debian and Fedora care about ABI symbols and
tracking them.
|
@rhubner Any chance you might pick this up again some day? Having a clean ABI would be nice for stability and maintainability. |
I rebased the patches in https://salsa.debian.org/debian/rocksdb/-/merge_requests/3 on latest 9.8.4 just to check if what happens, and I learned at the situation is still the same (same test build outcome, and adjacent code upstream is unchanged). |
Add new build flag HIDE_PRIVATE_SYMBOLS to allow compile shared library without exported private symbols. Work only in Release mode.
8c9409e
to
a1b33b0
Compare
Thanks @rhubner for looking into this. I applied the latest version of this on top of latest RocksDB version in Debian and build is failing due to undefined references. Build log at https://salsa.debian.org/otto/rocksdb/-/jobs/7087000. Links in the right sidebar will show you the exact code that went into the build.
|
Add new build flag
HIDE_PRIVATE_SYMBOLS
to allow compile shared library without exported private symbols.Work only in Release mode.
Fix #12929