Hi,
On 6/5/20 6:17 pm, Fabio Corradini Santander wrote:
... Cutting the long
paths of CRAN, the problem looks like (for r-oldrel-osx-x86_64):
...
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘uFTIR’ in dyn.load(file,
DLLpath = DLLpath, ...):
unable to load shared object '.../libs/uFTIR.so':
dlopen(.../libs/uFTIR.so, 6): Symbol not found:
_H5P_CLS_DATASET_CREATE_ID_g
Referenced from: .../libs/uFTIR.so
Expected in: flat namespace
in .../libs/uFTIR.so
Error: loading failed
_H5P_CLS_DATASET_CREATE_ID_g comes from the HDF5 library. You don't seem
to use it directly, and is probably a transitive dependency coming from
gdal, which you do link against, so it seems more like a problem with
gdal, not with your code. You could double check this by trying to
compile anything else against that gdal installation and see if it
works, or the fact that you are compiling an R package.
You will find many people on internet having exactly the same problem
but in other products, not R. It seems to boil down to a mismatch in how
hdf5 was compiled, and how hdf5 users (in this case, gdal) compile
against the library (with/without defining the H5_BUILT_AS_DYNAMIC_LIB
preprocessor macro). But again, this is probably on gdal's side, not yours.
Make sure you have a proper gdal installation; after that things should
work. If you want you could be more defensive about this, and add some
logic to your configure script to test if a binary compiled against gdal
runs correctly or not, and react accordingly (e.g., if gdal is a strong
dependency then you don't continue further into the compilation of your
package).
(The missing symbol for r-release-osx-x86_64 is a different
one: _jpeg_resync_to_restart)
No idea, but I'd suspect gdal here again, not your code.
Cheers,
Rodrigo
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
