Updating `sundialr` package for webr to CRAN version

[sn248]

Hi

I was wondering why the version installed on webr is older than the CRAN version of this package? Is there anything the package owner needs to do at their end?

thanks

[georgestagg]

Hi, the current version of the sundialr package does not build when compiling with Emscripten. It looks like version 0.1.5 compiled okay previously, so it is likely something to do with the switch to the cmake build system that Emscripten's emcc compiler doesn't like.

You can test compiling the package under WebAssembly by building the package manually using the {rwasm} R package. Documentation for getting started can be found here.

Once a version of the package supporting WebAssembly and without these build issues hits CRAN, it will be updated shortly after on both the R-Universe and the default webR WebAssembly binary repositories.

---

I took a look a little closer for you, and I've attached a log showing a build issue on my (macOS) machine, it looks like the error lies in this line:

wasm-ld: error: unknown argument: -headerpad_max_install_names

This flag doesn't seem to be supported under the Emscripten compiler, and it looks to be related to macOS in some way. Perhaps it is possible to tweak the cmake recipes so that the flag is not included when uname reports the system as Emscripten.

macos.log

---

I also tried compiling under Linux as the host machine (log also attached). Here the issue is different. The cmake build is successful, but we see errors of the form:

[...]
wasm-ld: error: duplicate symbol: N_VLinearSum_Serial
>>> defined in ../inst/lib/libsundials_idas.a(nvector_serial.c.o)
>>> defined in ../inst/lib/libsundials_cvodes.a(nvector_serial.c.o)

wasm-ld: error: duplicate symbol: N_VGetLength_Serial
>>> defined in ../inst/lib/libsundials_idas.a(nvector_serial.c.o)
>>> defined in ../inst/lib/libsundials_cvodes.a(nvector_serial.c.o)
[...]

when linking the R package file sundialr.so.

This indicates that the same object file nvector_serial.c.o is being compiled into two separate static libraries, -libsundials_idas and -libsundials_cvodes, and when both static libraries are linked into sundial.so we get two copies of some symbols (e.g. N_VGetLength_Serial). If possible, only one of these symbols should be exported and visible, duplicate symbols are not allowed.

The same is true of some symbols in sundials_system_memory.c.o.

linux.log