Trouble running the prebuilt binary on Ubuntu Linux v20

[jsta]

I get the following error trying to run the prebuilt linux binary:

error while loading shared libraries: libnetcdf.so.13: cannot open shared object file: No such file or directory

Then I tried building my own binary from source. It works fine on it's own (outside of GLM3r) by calling glm from the command line. However, trying to call my local binary within GLM3r (replacing exec/nixglm) I get maybe a dozen error messages similar to (where glm_local is my locally built executable):

/glm_local: /GLM3r/inst/extbin/nixGLM/libm.so.6: version `GLIBC_2.29' not found (required by /glm_local)

If I delete all the shared object (.so*) files in inst/extbin/nixGLM, I get no more errors and package execution works for me.

[jsta]

My preference would be to remove the exec/nixglm folder and have linux people build GLM from source. Most of the build complexity seems to in figuring out version compatibility between AED and GLM. I feel it's pretty straightforward as these things go. Perhaps providing a build script would be doable.

[robertladwig]

This seems to come down to cross-compiling issues between 20X and other Linux versions. We did test GLM3r primarily on Ubuntu 18.04 and Fedora (although for Fedora we also did deinstall the shared objects).

Alternatively to removing exec/nixglm, we could delete the Sys.setenv in run_GLMnix:

run_glmNIX <- function(sim_folder, verbose, system.args){
  glm_path <- system.file('exec/nixglm', package=packageName())
  
  Sys.setenv(LD_LIBRARY_PATH=paste(system.file('extbin/nixGLM', 
                                         package=packageName()), 
                                   Sys.getenv('LD_LIBRARY_PATH'), 
                                   sep = ":"))
  glm.systemcall(sim_folder, glm_path, verbose, system.args)

}

Personally, I'd prefer to keep a GLM Linux executable in GLM3r as users can be assured than that they are running the same version as a Windows or macOS user. This is especially important for another modeling project, LakeEnsemblR, that relies on available GLM executables for different OS. Also for LakeEnsemblR removing the Linux executable would fail our Travis test setup at the moment, as we're not compiling GLM from scratch for it.

[jsta]

Ooh, that sounds good. I hadn't realized that LD_LIBRARY_PATH was being overridden. At least don't run that line when GLM_PATH is set.