[R-pkg-devel] MacOS flat namespace

[Rodrigo Tobar]

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