Package requests munselinterpol, rootSolve, spacesXYZ adn spacesRGB

[codingthemystery]

munsellinterpol has three dependencies. I was able to create a WASM file but there's a problem with a .so file in rootSolve. It seems to be an issue with dynamic linking. If you can add the packages, it'll make life a lot easier :)

Error: Error in unknown source: package or namespace load failed for ‘munsellinterpol’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/usr/lib/R/library/rootSolve/libs/rootSolve.so':
Could not load dynamic lib: /usr/lib/R/library/rootSolve/libs/rootSolve.so
Error: bad export type for 'dls001_': undefined

[georgestagg]

This is difficult currently because the dls001 symbol used in rootSolve is defined as a Fortran COMMON block, and at the time of writing the LLVM WebAssembly backend does not support common symbols.

I know of no automated or general way to solve this problem right now. One trick I have used in the past is rewriting the Fortran source to use Fortran 90 modules to handle global state, but for lsodes.f that looks difficult. The code is long, and at first glance the use of the common symbols seems involved, being used over several functions.

So, in this case I think the only real approach is to wait. Eventually, one of the flang-new or LFortran compilers will support COMMON blocks for the WebAssembly backend, and then these packages should just compile and work.

[tpetzoldt]

Thanks @georgestagg for this explanation, even if its currently bad news. Unfortunately, it also breaks package deSolve, a central package in the field of differential equation-based models with quite a number of reverse depends and reverse imports. I agree that the use of COMMON blocks is strictly discouraged nowadays, but it was usual practice at the time of ODEPACK development, a collection of legacy Fortran algorithms, still widely used by many software packages even beyond the R world. R-Web assembly has an awesome potential and I would be thrilled if it could be made working.

[georgestagg]

I agree, it would be great to have this working.

I'm watching the development of LLVM flang and LFortran closely, and will update in this thread if there are any changes so that COMMON blocks become supported in Wasm output.

I've added the "help wanted" tag in case any compiler developers drop by and know of the best way to implement this in e.g. LLVM.