Re: [R-pkg-devel] Warnings from upstream C library in CRAN submission
Thank you Jeff and Simon for your feedback. I have filed your feedback as an issue to the SUNDIALS developers at - https://github.com/LLNL/sundials/issues/409 Thank you. On Sat, Feb 3, 2024 at 10:38 AM Satyaprakash Nayak wrote: > Hi > > I had a package 'sundialr' which was archived from CRAN. It is an interface > to some of the solvers in SUNDIALS ODE Solving library. I have fixed the > issue which was related to emails being forwarded from the maintainer's > email address. > > The repository code can be found at - https://github.com/sn248/sundialr > > I have updated the upstream library and now I am getting the following > warnings from CRAN which are all related to the upstream library. The > package compiles without any other issues and can be used. > > Flavor: r-devel-windows-x86_64 > Check: whether package can be installed, Result: WARNING > Found the following significant warnings: > ./sundials/sundials/sundials_hashmap.h:26:48: warning: conversion from > 'long long unsigned int' to 'long unsigned int' changes value from > '14695981039346656037' to '2216829733' [-Woverflow] > ./sundials/sundials/sundials_hashmap.h:27:48: warning: conversion from > 'long long unsigned int' to 'long unsigned int' changes value from > '1099511628211' to '435' [-Woverflow] > sundials/sundials/sundials_hashmap.h:26:48: warning: conversion from > 'long long unsigned int' to 'long unsigned int' changes value from > '14695981039346656037' to '2216829733' [-Woverflow] > sundials/sundials/sundials_hashmap.h:27:48: warning: conversion from > 'long long unsigned int' to 'long unsigned int' changes value from > '1099511628211' to '435' [-Woverflow] > sundials/sundials/sundials_profiler.c:71:24: warning: function > declaration isn't a prototype [-Wstrict-prototypes] > See 'd:/RCompile/CRANincoming/R-devel/sundialr.Rcheck/00install.out' for > details. > Used C++ compiler: 'g++.exe (GCC) 12.3.0' > > Flavor: r-devel-linux-x86_64-debian-gcc > Check: whether package can be installed, Result: WARNING > Found the following significant warnings: > sundials/sundials/sundials_profiler.c:71:41: warning: a function > declaration without a prototype is deprecated in all versions of C > [-Wstrict-prototypes] > See '/srv/hornik/tmp/CRAN/sundialr.Rcheck/00install.out' for details. > Used C++ compiler: 'Debian clang version 17.0.6 (5)' > > I am hesitant to change anything in the SUNDIALS library C code because I > don't understand the consequences of changing anything there. > > Any help will be kindly appreciated. > > Thank you. > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Warnings from upstream C library in CRAN submission
Hi I had a package 'sundialr' which was archived from CRAN. It is an interface to some of the solvers in SUNDIALS ODE Solving library. I have fixed the issue which was related to emails being forwarded from the maintainer's email address. The repository code can be found at - https://github.com/sn248/sundialr I have updated the upstream library and now I am getting the following warnings from CRAN which are all related to the upstream library. The package compiles without any other issues and can be used. Flavor: r-devel-windows-x86_64 Check: whether package can be installed, Result: WARNING Found the following significant warnings: ./sundials/sundials/sundials_hashmap.h:26:48: warning: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '14695981039346656037' to '2216829733' [-Woverflow] ./sundials/sundials/sundials_hashmap.h:27:48: warning: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '1099511628211' to '435' [-Woverflow] sundials/sundials/sundials_hashmap.h:26:48: warning: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '14695981039346656037' to '2216829733' [-Woverflow] sundials/sundials/sundials_hashmap.h:27:48: warning: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '1099511628211' to '435' [-Woverflow] sundials/sundials/sundials_profiler.c:71:24: warning: function declaration isn't a prototype [-Wstrict-prototypes] See 'd:/RCompile/CRANincoming/R-devel/sundialr.Rcheck/00install.out' for details. Used C++ compiler: 'g++.exe (GCC) 12.3.0' Flavor: r-devel-linux-x86_64-debian-gcc Check: whether package can be installed, Result: WARNING Found the following significant warnings: sundials/sundials/sundials_profiler.c:71:41: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes] See '/srv/hornik/tmp/CRAN/sundialr.Rcheck/00install.out' for details. Used C++ compiler: 'Debian clang version 17.0.6 (5)' I am hesitant to change anything in the SUNDIALS library C code because I don't understand the consequences of changing anything there. Any help will be kindly appreciated. Thank you. [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] package fails with parallel make - would forcing a serial version work?
Thank you Paul and Avi for your response. Indeed, there was an error in Makefile which could have been contributing to the issues with parallel make. I have re-submitted after correcting for the mistakes in Makefile, hopefully it will not throw errors with parallel make now. Thank you for your advice. Satyaprakash On Mon, Jan 14, 2019 at 2:01 PM Avraham Adler wrote: > If you want to use .NOTPARRALLEL, that’s considered non-portable as it’s > GNU-make specific, (I got an email from Dr. Ripley this week) so you have > to add Gnu Make to the system requirements in the DESCRIPTION or find the > right sequence of targets to ensure order is maintained even in parallel > make. > > Avi > > On Mon, Jan 14, 2019 at 1:29 PM Paul Gilbert > wrote: > >> (I didn't see an answer to this, so ...) >> >> I think using .NOTPARALLEL will usually get rid of the error but, in my >> experience, this problem is usually caused by an incorrect or incomplete >> Makefile. When not done in parallel this missing target is usually >> getting done first as a side-affect of something that happens before and >> usually finishes before it is needed. Your luck does not hold in >> parallel. The better fix is to correct your Makefile. >> >> Paul >> >> On 1/10/19 4:54 PM, Satyaprakash Nayak wrote: >> > Dear R package developers >> > >> > I published a package on CRAN last year (sundialr) which is now failing >> > with as it is not make to compile a static library with parallel make. >> > >> > In this package, I compile a static library (libsundials_all.a) from >> source >> > files of a third party. The specifics of compiling the static library >> can >> > be found at - >> https://github.com/sn248/sundialr/blob/master/src/Makevars >> > >> > Now, I got the following error message from CRAN (actually, I was >> informed >> > of this before, but had neglected to fix it). Here is the message from >> one >> > of the CRAN maintainers .. >> > >> > >> *** >> > This have just failed to install for me with a parallel make: >> > >> > g++ -std=gnu++98 -std=gnu++98 -shared >> > -L/data/blackswan/ripley/extras/lib64 -L/usrlocal/lib64 -o sundialr.so >> > cvode.o RcppExports.o -L/data/blackswan/ripley/R/R-patched/lib -lRlapack >> > -L/data/blackswan/ripley/R/R-patched/lib -lRblas -lgfortran -lm >> > -lquadmath -L../inst/ ../inst/libsundials_all.a >> > g++: error: ../inst/libsundials_all.a: No such file or directory >> > make[1]: *** [/data/blackswan/ripley/R/R-patched/share/make/shlib.mk:6: >> > sundialr.so] Error 1 >> > >> * >> > >> > It seems the package fails to generate the static library with the >> parallel >> > make. The easiest solution I could think of for this problem was to >> force a >> > serial version of make using the .NOTPARALLEL phony command in Makevars >> and >> > Makevars.win(https://github.com/sn248/sundialr/blob/master/src/Makevars). >> I >> > have made this change and it seems to work on my machine and on testing >> > with TravisCI and Appveyor(https://github.com/sn248/sundialr). >> > >> > However, before I re-submit to CRAN, I wanted to get an opinion as to >> will >> > this be enough to get rid of the error with parallel make? >> > >> > Any suggestions would be very much appreciated, thank you! >> > Satyaprakash >> > >> > [[alternative HTML version deleted]] >> > >> > __ >> > R-package-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > >> >> __ >> R-package-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-package-devel >> > -- > Sent from Gmail Mobile > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] package fails with parallel make - would forcing a serial version work?
Dear R package developers I published a package on CRAN last year (sundialr) which is now failing with as it is not make to compile a static library with parallel make. In this package, I compile a static library (libsundials_all.a) from source files of a third party. The specifics of compiling the static library can be found at - https://github.com/sn248/sundialr/blob/master/src/Makevars Now, I got the following error message from CRAN (actually, I was informed of this before, but had neglected to fix it). Here is the message from one of the CRAN maintainers .. *** This have just failed to install for me with a parallel make: g++ -std=gnu++98 -std=gnu++98 -shared -L/data/blackswan/ripley/extras/lib64 -L/usrlocal/lib64 -o sundialr.so cvode.o RcppExports.o -L/data/blackswan/ripley/R/R-patched/lib -lRlapack -L/data/blackswan/ripley/R/R-patched/lib -lRblas -lgfortran -lm -lquadmath -L../inst/ ../inst/libsundials_all.a g++: error: ../inst/libsundials_all.a: No such file or directory make[1]: *** [/data/blackswan/ripley/R/R-patched/share/make/shlib.mk:6: sundialr.so] Error 1 * It seems the package fails to generate the static library with the parallel make. The easiest solution I could think of for this problem was to force a serial version of make using the .NOTPARALLEL phony command in Makevars and Makevars.win(https://github.com/sn248/sundialr/blob/master/src/Makevars). I have made this change and it seems to work on my machine and on testing with TravisCI and Appveyor(https://github.com/sn248/sundialr). However, before I re-submit to CRAN, I wanted to get an opinion as to will this be enough to get rid of the error with parallel make? Any suggestions would be very much appreciated, thank you! Satyaprakash [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Help with reproducing (and solving) clang-UBSAN and Solaris installation errors
Thank you very much Kevin for your response.
I got R development with clang-6.0 working on a Ubuntu machine yesterday so
will investigate this further to see if there is anything more subtle going
on w.r.t. UBSAN issue and report here.
Regarding Solaris, I have code such as
SOURCES = $(cvode.cpp RcppExports.cpp)
OBJECTS = $(SOURCES:.cpp=.o)
Maybe that's causing a problem, I read section 1.6 of R extensions
mentioned
" Commonly misused GNU extensions are conditional inclusions (ifeq and the
like), ${shell ...}, ${wildcard ...} and similar, and the use of +=68
and :=
. "
I will try with
OBJECTS = cvode.o RcppExports.o
but since, rhub is not giving an error, I am not sure how I can really test
this.
Thanks for your suggestion about
SystemRequirements: GNU make
That may be the final solution for me to get this working on Solaris.
Best
Satya
On Mon, Jul 9, 2018 at 11:48 AM Kevin Ushey wrote:
> The UBSAN error:
>
> cvode.cpp:58:11: runtime error: call to function
> cv_Roberts_dns(double, Rcpp::Vector<14, Rcpp::PreserveStorage>)
> through pointer to incorrect function type 'Rcpp::Vector<14,
> PreserveStorage> (*)(double, Rcpp::Vector<14, PreserveStorage>)'
>
> /tmp/RtmplnLW4G/sourceCpp-x86_64-pc-linux-gnu-0.12.17/sourcecpp_a916f8734/filea91617630abf.cpp:9:
> note: cv_Roberts_dns(double, Rcpp::Vector<14, Rcpp::PreserveStorage>)
> defined here
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior cvode.cpp:58:11 in
>
> sounds like it might be a false positive, since the function
> signatures do appear to be identical. Of course, there may be
> something more subtle going on, but absent any other ill effects I
> think the message can be ignored. For what it's worth, one similar
> false positive is reported here at
> https://github.com/google/sanitizers/issues/911.
>
> The actual compilation error you're seeing on Solaris:
>
> mksh: Fatal error in reader: = missing from replacement macro reference
>
> implies that you're likely trying to use a GNU-ism in your Makefile /
> Makevars. R requires that Makefiles be portable by default, as per
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Using-Makevars
> .
> If you _really_ need the GNU-isms, you can add something like:
>
> SystemRequirements: GNU make
>
> to request that GNU make is used on all platforms your package is built on.
>
> Best,
> Kevin
>
> On Sun, Jul 8, 2018 at 3:53 AM SN248 wrote:
> >
> > Dear all
> >
> > I recently submitted an R package to CRAN which was accepted. However,
> the
> > package is failing additional tests, i.e., it fails to install on Solaris
> > and also produces a clang-UBSAN issue. These can be seen here
> >
> > https://cran.r-project.org/web/checks/check_results_sundialr.html
> >
> > I tried to reproduce the installation error for Solaris and clang-UBSAN
> > issue using rhub (R package). However, in both cases, I don't see any
> error
> > reported by rhub.
> >
> > Solaris installation went fine (Oracle Solaris 10, x86, 32 bit, R-patched
> > (experimental)). See the report below:
> >
> >
> https://builder.r-hub.io/status/original/sundialr_0.1.0.tar.gz-b13f34c036448a13cbc147f4fb2cf37b
> >
> > and
> >
> > No errors were reported when I run 'check_with_sanitizers()' command (I
> > assume that is the right command to generate clang-UBSAN errors, though
> the
> > Platform information is - Debian Linux, R-devel, GCC ASAN/UBSAN). See the
> > report of the test below:
> >
> >
> https://builder.r-hub.io/status/original/sundialr_0.1.0.tar.gz-a38aa86e16494f41b6f2e2e093547b7b
> >
> > I am not sure how to proceed with debugging those errors as I am not able
> > to reproduce them. Is there any way to test installation on Solaris (I
> > don't have access to one, unfortunately) and reproduce clang-UBSAN issue.
> >
> > The clang-UBSAN issue _may_ be related to Rcpp::XPtr and _may_ remain
> > unresolved (based on the thread in Rcpp-devel forum earlier (I could have
> > mis-interpreted the whole discussion there) -
> >
> http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2017-July/009656.html
> > )
> >
> > Any help in how to reproduce these issues will be highly appreciated.
> >
> > On a separate note - in case these issues remain unresolved, is the
> package
> > doomed to go to CRAN archives then? The package installation and running
> > examples went without error/warning/note on all the platforms in rhub.
> >
> > Thanks
> > SN
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Can't build package but can load it with devtools::load_all()
Just an update - I re-installed libSBML and now devtools::load_all() is giving an error > devtools::load_all() > Loading Rcppsbml > Error in dyn.load(dllfile) : > unable to load shared object '//Rcppsbml/src/Rcppsbml.so': > dlopen(//Rcppsbml/src/Rcppsbml.so, 6): Symbol not found: > __ZN7libsbml10SBMLReader16readSBMLFromFileERKNSt3__112basic_stringIcNS1_11char_traitsIcEENS1_9allocatorIc is the path to package directory Thank you Satyaprakash Nayak On Sun, Jul 31, 2016 at 11:32 PM, Satyaprakash Nayak <sn...@cornell.edu> wrote: > Hi > > I am trying to build a package with interfaces with C library libSBML > <http://sbml.org/Software/libSBML> (although a package libSBML exists). > When I try to build the package using "Clean and Rebuild" command in > RStudio, I am getting the following error > > ** R >> ** preparing package for lazy loading >> ** help >> *** installing help indices >> ** building package indices >> ** testing if installed package can be loaded >> Error in dyn.load(file, DLLpath = DLLpath, ...) : >> unable to load shared object >> '/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcppsbml/libs/Rcppsbml.so': >> >> dlopen(/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcppsbml/libs/Rcppsbml.so, >> 6): Library not loaded: libsbml.5.dylib >> Referenced from: >> /Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcppsbml/libs/Rcppsbml.so >> Reason: image not found >> Error: loading failed >> Execution halted >> ERROR: loading failed >> * removing >> ‘/Library/Frameworks/R.framework/Versions/3.3/Resources/library/Rcppsbml’ >> Exited with status 1. > > > However, if I issue the command > > devtools::load_all() > > after "Clean and Rebuild" command, I get the message > > Loading Rcppsbml > > > and I can also use the functions defined in the package! However, as soon > as I restart my R session, I cannot load the library (understandable, as I > don't think the package is built correctly). > > Based on the error shown, I think libsbml.5.dylib is not being loaded, > however, it is there in the /usr/local/lib folder. > > The code for this package can be found at > > https://github.com/sn248/Rcppsbml > > Any help in resolving this error would be highly appreciated! > > Thank you > Satyaprakash Nayak > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
