Should RTLD_LOCAL be used for dlopen of compression filters

HDF5 Library
1

Am being lazy and looking only at 1.10.4 sources but…

find ~/silo/hdf5-1.10.4/src -type f -exec grep dlopen {} ; -print
# define H5PL_OPEN_DLIB(S) dlopen(S, RTLD_LAZY)
# define H5PL_CLR_ERROR HERROR(H5E_PLUGIN, H5E_CANTGET, “can’t dlopen:%s”, dlerror())

The default behavior of dlopen() assumes RTLD_GLOBAL which means all symbols loaded wind up in the loading image’s global namespace. I am thinking HDF5 should be including RTLD_LOCAL to prevent that because the loading image could be using lib(s) (but different versions) the plugin is compiled with explicitly as well.

2

This man page indicates that RTLD_LOCAL is a default

RTLD_LOCAL
This is the converse of RTLD_GLOBAL, and the default if
neither flag is specified. Symbols defined in this shared
object are not made available to resolve references in
subsequently loaded shared objects.

But maybe I am missing something…or are you suggesting to add to the parameters to be precise?

3

Interesting - on MacOS, it’s the opposite:

 One of the following flags may be ORed into the mode argument:

 RTLD_GLOBAL  Symbols exported from this image (dynamic library or bundle)

              will be available to any images build with -flat_namespace

              option to ld(1) or to calls to **dlsym**() when using a special

              handle.

 RTLD_LOCAL   Symbols exported from this image (dynamic library or bundle)

              are generally hidden and only availble to **dlsym**() when

              directly using the handle returned by this call to **dlopen**().

 If neither RTLD_GLOBAL nor RTLD_LOCAL is specified, the default is

 RTLD_GLOBAL.

Seems like it should be set explicitly, since it varies across systems.  :-/

Quincey
4

Thank you, Quincey! I entered JIRA issue HDFFV-11127 :slight_smile:

5

Yes, thanks Quincey and Elena. I was reading from OSX man pages ;). Agree now it should be explicitly specified by HDF5.