You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All these become available to the ELF loader as targets to resolve symbols to.
As long as DuckDB is the only JNI in this context, that can be OK, I suppose. But whenever an other shared object needs resolving after DuckDB, then this might resolve to a DuckDB exported symbol - unintentionally.
So what DuckDB is doing here to (potentially) other is the same as RocksDB is doing to DuckDB in #14
The DuckDB JNI build of the C++ library should only really export what must be exported, to encapsulate the DuckDB JNI better. Whether or not the DuckDB "owned" C++ exports are exported could be debatable, but exporting icu_66::, for instance, feels wrong.
The only items requiring exporting seem to be the various JNI methods, e.g.
The shared object provisioned for JNI integration pollutes the ELF symbol namespace by exporting functions which are not part of the the DuckDB API.
To reproduce, unpack the JAR to get access to the
libduckdb_java.so_linux_amd64
then runNote exports such as
All these become available to the ELF loader as targets to resolve symbols to.
As long as DuckDB is the only JNI in this context, that can be OK, I suppose. But whenever an other shared object needs resolving after DuckDB, then this might resolve to a DuckDB exported symbol - unintentionally.
So what DuckDB is doing here to (potentially) other is the same as RocksDB is doing to DuckDB in #14
The DuckDB JNI build of the C++ library should only really export what must be exported, to encapsulate the DuckDB JNI better. Whether or not the DuckDB "owned" C++ exports are exported could be debatable, but exporting
icu_66::
, for instance, feels wrong.The only items requiring exporting seem to be the various JNI methods, e.g.
The text was updated successfully, but these errors were encountered: