I am working with a function "foo" that explicitly dynamically loads a shared object library or "DLL", doing something like dyn.load("bar.so"). This is a debugging exercise so I make changes to the underlying Fortran code (yes, I acknowledge that I am a dinosaur) remake the DLL "bar.so" and then run foo again. This is all *without* quitting and restarting R. (I'm going to have to do this a few brazillion times, and I want the iterations to be as quick as possible.) This seems to work --- i.e. foo seems to obtain the latest version of bar.so. But have I just been lucky so far? (I have not experimented heavily). Am I running risks of leading myself down the garden path? Are there Traps for Young (or even Old) Players lurking about? I would appreciate Wise Counsel. cheers, Rolf Turner -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 P. S.: > sessionInfo() R version 3.4.3 (2017-11-30) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.3 LTS Matrix products: default BLAS: /usr/local/lib64/R/lib/libRblas.so LAPACK: /usr/local/lib64/R/lib/libRlapack.so locale: [1] LC_CTYPE=en_NZ.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_NZ.UTF-8 LC_COLLATE=en_NZ.UTF-8 [5] LC_MONETARY=en_NZ.UTF-8 LC_MESSAGES=en_NZ.UTF-8 [7] LC_PAPER=en_NZ.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_NZ.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] misc_0.0-16 loaded via a namespace (and not attached): [1] compiler_3.4.3 deldir_0.1-15 Matrix_1.2-10 [4] spatstat.utils_1.8-0 mgcv_1.8-22 abind_1.4-5 [7] spatstat.data_1.2-0 spatstat_1.55-0 rpart_4.1-11 [10] nlme_3.1-131 grid_3.4.3 polyclip_1.6-1 [13] lattice_0.20-35 goftest_1.1-1 tensor_1.5
Hello, In such cases, with C code, I call dyn.unload before loading the modified shared lib again. I don't know if this changed recently, but it used to be needed or else R wouldn't load the new lib. When I call dyn.unload followed by dyn.load I never had problems. (Or the other way around, call dyn.unload before modifying the C code.) Hope this helps, Rui Barradas On 3/1/2018 8:52 AM, Rolf Turner wrote:> > I am working with a function "foo" that explicitly dynamically loads a > shared object library or "DLL", doing something like dyn.load("bar.so"). > ?This is a debugging exercise so I make changes to the underlying > Fortran code (yes, I acknowledge that I am a dinosaur) remake the DLL > "bar.so" and then run foo again.? This is all *without* quitting and > restarting R.? (I'm going to have to do this a few brazillion times, and > I want the iterations to be as quick as possible.) > > This seems to work --- i.e. foo seems to obtain the latest version of > bar.so.? But have I just been lucky so far?? (I have not experimented > heavily). > > Am I running risks of leading myself down the garden path?? Are there > Traps for Young (or even Old) Players lurking about? > > I would appreciate Wise Counsel. > > cheers, > > Rolf Turner >
Good question Rolf. Rui, thanks for pointing out dyn.unload. When I started using Rcpp a couple of years ago I got burned by stale .so enough times that I adopted a policy of recompile-then-start new R session. My workflow does not include Rolf's "brazillion" repeats, so the overhead of this approach has not been too painful. The documentation for dyn.unload (via ?dyn.unload) includes the following statement: "The function dyn.unload unlinks the DLL. Note that unloading a DLL and then re-loading a DLL of the same name may or may not work: on Solaris it uses the first version loaded." Eric On Thu, Mar 1, 2018 at 2:21 PM, Rui Barradas <ruipbarradas at sapo.pt> wrote:> Hello, > > In such cases, with C code, I call dyn.unload before loading the modified > shared lib again. > I don't know if this changed recently, but it used to be needed or else R > wouldn't load the new lib. When I call dyn.unload followed by dyn.load I > never had problems. > (Or the other way around, call dyn.unload before modifying the C code.) > > Hope this helps, > > Rui Barradas > > On 3/1/2018 8:52 AM, Rolf Turner wrote: > >> >> I am working with a function "foo" that explicitly dynamically loads a >> shared object library or "DLL", doing something like dyn.load("bar.so"). >> This is a debugging exercise so I make changes to the underlying Fortran >> code (yes, I acknowledge that I am a dinosaur) remake the DLL "bar.so" and >> then run foo again. This is all *without* quitting and restarting R. (I'm >> going to have to do this a few brazillion times, and >> I want the iterations to be as quick as possible.) >> >> This seems to work --- i.e. foo seems to obtain the latest version of >> bar.so. But have I just been lucky so far? (I have not experimented >> heavily). >> >> Am I running risks of leading myself down the garden path? Are there >> Traps for Young (or even Old) Players lurking about? >> >> I would appreciate Wise Counsel. >> >> cheers, >> >> Rolf Turner >> >> > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posti > ng-guide.html > and provide commented, minimal, self-contained, reproducible code. >[[alternative HTML version deleted]]