[R-pkg-devel] New Package Removal because Shared Library Too Large from Debugging Symbols
Dirk Eddelbuettel
edd @end|ng |rom deb|@n@org
Sat Jan 20 21:01:29 CET 2024
Johann,
On 20 January 2024 at 14:38, Johann Gaebler wrote:
| Hi everyone,
|
| I received the following message regarding `rar` <https://cran.r-project.org/package=rar>, a package that I put up on CRAN two days ago:
|
| > Dear maintainer,
| >
| > Please see the problems shown on
| > <https://cran.r-project.org/web/checks/check_results_rar.html>.
| >
| > Please correct before 2024-02-02 to safely retain your package on CRAN.
|
| The issue is that the compiled libraries are too large. The Mac CRAN checks turned up the following note:
No you read that wrong. That is NOT the issue. That is a mere 'Note'.
Your issue is the bright red link labeled 'LTO' on that pagem and going to
https://www.stats.ox.ac.uk/pub/bdr/LTO/rar.out
where it details an error on that platform / compilation choice:
g++-13 -std=gnu++17 -shared -L/usr/local/gcc13/lib64 -L/usr/local/lib64 -o rar.so cpp11.o distpt.o iter.o max.o min.o regdata.o sens.o test-distpt.o test-iter.o test-max.o test-min.o test-regdata.o test-runner.o test-sens.o
cpp11.cpp:18:13: warning: 'run_testthat_tests' violates the C++ One Definition Rule [-Wodr]
18 | extern SEXP run_testthat_tests(void *);
| ^
/data/gannet/ripley/R/test-dev/testthat/include/testthat/testthat.h:172:17: note: 'run_testthat_tests' was previously declared here
172 | extern "C" SEXP run_testthat_tests(SEXP use_xml_sxp) {
| ^
make[2]: Leaving directory '/data/gannet/ripley/R/packages/tests-LTO/rar/src'
installing to /data/gannet/ripley/R/packages/tests-LTO/Libs/rar-lib/00LOCK-rar/00new/rar/libs
This 'violates the C++ One Definition Rule' is something that started with
g++-13, if memory serves. Without looking at the code, I think you did
something that lead to a symbol being included multiple times, and it should
not be.
Cheers, Dirk
| > installed size is 8.9Mb
| > sub-directories of 1Mb or more:
| > libs 8.7Mb
|
| I have not been able to reproduce the issue either locally or on any machine I have ready access to. I have built it on some of the Rhub and R-Project build systems, and the same issue (with very different `libs` sizes) came up on some of them:
|
| • (RHub) Ubuntu Linux 20.04.1 LTS, R-release, GCC: 18.2Mb,
| • (RHub) Fedora Linux, R-devel, clang, gfortran: 6.8Mb,
| • (R-Project) r-release-macosx-arm64: 8.5Mb.
|
| Based on trying to read up about this, it seems that this is a pretty common problem <http://dirk.eddelbuettel.com/blog/2017/08/14/#009_compact_shared_libraries> for compiled packages because of debugging symbols getting inserted into the shared library file. Using the fix from that blog post where you modify the Makevars to strip debugging symbols from the shared library seems to solve the issue on those build systems, so I feel reasonably confident that this is what’s going on.
|
| Apparently many, many existing packages on CRAN have the same issue. However, I’m very new to R package development, so I’m not exactly sure what to do. I have two questions:
|
| 1. Is there anything I need to “fix” here, or should I just make contact with the CRAN folks and bring the fact that this is being caused by debugging symbols to their attention?
| 2. Regardless of whether or not I have to fix this issue for CRAN, is there a way to strip out the debugging symbols that comports with CRAN policies? The method suggested in the blog post above (adding a phony target in `Makevars` that strips the shared library) seems not to be CRAN-compliant, but I could be mistaken about that. (In particular, I had to modify it locally to get it to run, so I’m not sure what the platform-independent version of it looks like.)
|
| Thanks in advance for the help!
|
| Sincerely,
| Johann D. Gaebler
| [[alternative HTML version deleted]]
|
| ______________________________________________
| R-package-devel using r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
More information about the R-package-devel
mailing list