Hi!
It may be a problem with calling those functions before HDF5 filters
are invoked and plugins are loaded. Such could happen in global
constructors before a main() function is called, where this path is
modified. Getting control over the order of global constructors in a C++
application is possible but can be difficult. Having such a runtime-API
to modify the load path would solve some problems, for instance loading
plugins from the application's install directory rather than a fixed
compiled-in path - which is something I'd need in my applications. But
for this I'm currently using a patch such that the HDF5_PLUGIN_PATH may
contain a special two-character as placeholder for the application's
install directory - for now, that is "@0" - and HDF5 replaces the
statically compiled HDF5_PLUGIN_PATH containing this two-character with
the directory available at runtime. This solves that problem in a
constructor-safe way. Your scenario may be different though.
Werner
On 03.03.2017 09:43, Андрей Парамонов wrote:
Hello!
My usage scenario is a big Windows application with a lot of dlls,
some of which use HDF5 library. HDF5 code uses Dynamically Loaded
Plugin Filters:
https://support.hdfgroup.org/HDF5/doc1.8/Advanced/DynamicallyLoadedFilters/HDF5DynamicallyLoadedFilters.pdf
The filters are deployed in a local directory which is activated via
modifying process HDF5_PLUGIN_PATH env.variable, just prior to loading
the library. That works fine, and important thing is that user can
just drop new plugins in that directory to support newer files.
However, it appears that in some cases plugin search fails. HDF5
library retrieves HDF5_PLUGIN_PATH via
HDgetenv
which is defined as
#define HDgetenv(S) getenv(S)
According to
http://stackoverflow.com/questions/10636768/does-getenv-cache-the-result/10636993#10636993
"A process inherits the environment from the process creating the new
process. This is held in memory."
In the application I do not use C runtime (the implementation language
is not C), so I use SetEnvironmentVariable:
https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms686206(v=vs.85).aspx
It appears that if I modify HDF5_PLUGIN_PATH before C runtime is
loaded for the first time in the application, all is fine. However if
I call SetEnvironmentVariable after C runtime is already loaded, it
has no effect for HDF5.
The application is huge, and it's very hard to control the moments C
runtime and HDF5 library are loaded. I wonder -- does it make sense to
add HDF5 procedures to verbosely modify plugin search path, something
like
herr_t H5PLadd_path(const char *name)
herr_t H5PLrem_path(const char *name)
?
The above procedures could use HDsetenv, which is otherwise not
accessible (from non-C applications).
(I think similar motivation led to exposing H5free_memory procedure.)
What do you think?
Best wishes,
Andrey Paramonov
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Center for Computation & Technology at Louisiana State University (CCT/LSU)
2019 Digital Media Center, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
_______________________________________________
Hdf-forum is for HDF software users discussion.
[email protected]
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5
