[R-pkg-devel] Reducing installed package size with --strip-debug
Hi, Based on Dirk's blog post [1] about stripping debug information from the shared object of my package `s2` I reduced the shared object file size from 7 to 0.7 MB and get rid of a NOTE about the installed package size (on my local Linux machine). Dirk suggests that one could conditionally do this in the Makevars file if the strip tool is available (typically the case on Linux). Does anybody know what CRAN's take is on this? Cheers, Ege [1]: http://dirk.eddelbuettel.com/blog/2017/08/14/#009_compact_shared_libraries -- Ege Rubak, Associate Professor, Department of Mathematical Sciences, Aalborg University Skjernvej 4A, 9220 Aalborg East, Denmark Phone: (+45)99408861 Mobile: (+45)30230252 Email: ru...@math.aau.dk __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Reducing installed package size with --strip-debug
On 31 October 2017 at 15:02, Ege Rubak wrote: | Based on Dirk's blog post [1] about stripping debug information from the | shared object of my package `s2` I reduced the shared object file size | from 7 to 0.7 MB and get rid of a NOTE about the installed package size | (on my local Linux machine). | | Dirk suggests that one could conditionally do this in the Makevars file | if the strip tool is available (typically the case on Linux). Does | anybody know what CRAN's take is on this? The "BDR Doctrine" still stands: no non-portable code in src/Makevars. So the best I found (as a "live test") was this in RcppClassic (and I indent what is one long line) @if test -e "/usr/bin/strip" & \ test -e "/bin/uname" & \ [[ `uname` == "Linux" ]]; then \ /usr/bin/strip --strip-unneeded $(USERLIB); \ fi But but but ... this is in a package which already has an expanded src/Makevars. For the simple default one ... I have found nothing better than a _purely local_ settings in ~/.R/Makevars: SHLIB_CXXLDFLAGS = -Wl,-S -shared SHLIB_CXX11LDFLAGS = -Wl,-S -shared SHLIB_CXX14LDFLAGS = -Wl,-S -shared SHLIB_FCLDFLAGS = -Wl,-S -shared SHLIB_LDFLAGS = -Wl,-S -shared as described in the first follow-up to the link you quoted: http://dirk.eddelbuettel.com/blog/2017/08/14#009_compact_shared_libraries It is somewhat sad that we cannot portably set this for packages (at least not as far as I know), and equally sad that we cannot augment the setting in $(RHOME)/etc/Makeconf from inside a running R session. Also see the second follow-up to the link you posted; the file size changes are nothing short of staggering. http://dirk.eddelbuettel.com/blog/2017/08/20#010_stripping_shared_libraries Dirk | | Cheers, | Ege | | [1]: | http://dirk.eddelbuettel.com/blog/2017/08/14/#009_compact_shared_libraries | | -- | Ege Rubak, Associate Professor, | Department of Mathematical Sciences, Aalborg University | Skjernvej 4A, 9220 Aalborg East, Denmark | Phone: (+45)99408861 | Mobile: (+45)30230252 | Email: ru...@math.aau.dk | | __ | R-package-devel@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-package-devel -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Package valgrind problem I can't solve: Direction?
Wow: Thanks again. You are going above and beyond Iñaki which I appreciate greatly. But same error message appears, even after fixing (both the relerr, which I had already attended to, and the lambda issue). I have since initialised *every* variable in the subroutine smallp (even the *input* variables to some arbitrary value to try to work out what is causing the issue) yet the error persists. There surely cannot be any uninitialized variables now *every* var in the subroutine is explicitly initialised. That tells me that there is nothing I can do to remove the error. If everything is initialised… Frustrated… And wasting so much time! Thanks for any help from anyone. P. On 30/Oct/17, 9:06 pm, "Iñaki Úcar" wrote: 2017-10-30 0:54 GMT+01:00 Peter Dunn : > Thanks for this direction. > > But I am still confused, as the problem persists after attending to any > possible issue: That piece of identified code only has four variables, and I > can account for them all. > > The two variables its and aimrerr are now explicitly initialised. So they > cannot be the problem. > > The variables maxit and relerr are inputs to the subroutine... and both are > explicitly initialised in the only subroutine which calls smallp. So I can’t > see how that can be a problem. (Clearly they cannot be initialised in the > subroutine smallp or their input values are overwritten.) Found it. "relerr" may be uninitialised because "w" is uninitialised in smallp (tweedie 2.2.5, line 2169). When you try to debug this kind of things, you must track not only explicit initialisations, but also all the assignments with possibly uninitialised variables. BTW, I also see: tweedie.f:335:0: if ( funvalue .LT. exp(-lambda) ) then Warning: 'lambda' may be used uninitialized in this function [-Wmaybe-uninitialized] Regards, Iñaki USC, Locked Bag 4, Maroochydore DC, Queensland, 4558 Australia. CRICOS Provider No: 01595D Please consider the environment before printing this email. This email is confidential. If received in error, please delete it from your system. [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
