Re: [R-pkg-devel] Replicate solaris errors
In this case, using r-hub while removing the suggested dependencies (and commenting related unit tests) should work. The drawback is that r-hub for solaris installs all the dependencies at every build (as far as I understand), so hunting for a segfault will be extremely time-consuming, but I will still probably do that if I can't build R on solaris' VM. I was hoping that other people faced similar issues with replicating solaris builds. At https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Solaris, it is mentioned that "a little juggling of paths was needed to ensure GNU libiconv (in /usr/local) was used rather than the Solaris iconv". If I understand correctly, this is done through adding the line R_LD_LIBRARY_PATH="/opt/developerstudio12.5/lib:/usr/local/lib:/opt/csw/lib" to config.site (as is done in my gist). However, I don't get why this is not taken into account when doing ./configure afterwards. Somewhat related: if being able to build and unit test on an R build for solaris 10 with solaris studio 12.5 as a compiler is mandatory for a package to remain on CRAN, why is no such R build on CRAN website? This would be extremely helpful. Or does someone has more detailed guidelines to build R for build for solaris 10 with solaris studio 12.5 that would be targeted at a complete solaris noob? While I appreciate the guidelines in the R manual and the detailed config.site used for the checks by CRAN ( https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86), they are unfortunately insufficient for me, although it's likely due to the fact that I don't know anything about solaris in the first place. On Sat, Aug 11, 2018 at 3:29 PM Iñaki Úcar wrote: > El sáb., 11 ago. 2018 a las 20:41, Thibault Vatter > () escribió: > > > > Yes, the non-portable call to log which causes the current build to fail > on solaris has been corrected in a development version. However, the > segfault that we don't understand and were asked to correct was present in > the previous versions (e.g., 0.2.8.1.0 and 0.2.7.1.0), and we believe that > it is likely to reappear if we resubmit with only the non-portable log call > corrected. > > > > This is why, in order to avoid resubmitting with the segfault still > there and having the package removed from CRAN, we would like to be able to > replicate the solaris build. > > I see. About rhub, you could ask Gábor to add udunits2 to that machine > (this is part of the external software installed on CRAN). Or you can > remove that dependency until you find that bug: your package suggests > ggraph, which depends on ggforce, which depends on units, which needs > udunits2. > > The last time I dealt with an error with compiled code on Solaris was > on the SPARC machine (now dead; I won't miss it). I managed to recover > an old SPARC server from a forgotten room, install everything and test > it, but I don't remember the installation procedure, sorry. But I'd > rather try rhub before following that path again. > > Iñaki > > > > > On Sat, Aug 11, 2018 at 2:17 PM Iñaki Úcar wrote: > >> > >> El sáb., 11 ago. 2018 a las 19:30, Thibault Vatter > >> () escribió: > >> > > >> > Dear package developers, > >> > > >> > We've recently received an email letting us know that our package > >> > rvinecopulib ( > >> > https://cran.r-project.org/web/packages/rvinecopulib/index.html) > would be > >> > removed from CRAN unless the errors from the solaris build were > corrected. > >> > > >> > Note that the package compile and the unit tests pass on the other > test > >> > platforms from CRAN and even a local R devel build with ASAN / UBSAN > >> > sanitizers. On solaris, the package compiles but a segfault is > produced by > >> > one unit test for a reason that we still don't understand. > >> > >> Are you talking about a new development version that is not still on > >> CRAN? Because the current CRAN version fails to install. > >> > >> Iñaki > >> > >> > > >> > To replicate the issue, I tried to mimic CRAN's solaris config ( > >> > https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86) in > a > >> > virtual machine following the steps in the gist below (based on > Jeroen's): > >> > > >> > https://gist.github.com/tvatter/b2503f03fcd604ff764ffe4b979afcb6 > >> > > >> > Note that the "--with-readline=no" configure option at the end was > added > >> > because I got "configure: error: --with-readline=yes (default) and > >> >
Re: [R-pkg-devel] Replicate solaris errors
Yes, the non-portable call to log which causes the current build to fail on solaris has been corrected in a development version. However, the segfault that we don't understand and were asked to correct was present in the previous versions (e.g., 0.2.8.1.0 and 0.2.7.1.0), and we believe that it is likely to reappear if we resubmit with only the non-portable log call corrected. This is why, in order to avoid resubmitting with the segfault still there and having the package removed from CRAN, we would like to be able to replicate the solaris build. On Sat, Aug 11, 2018 at 2:17 PM Iñaki Úcar wrote: > El sáb., 11 ago. 2018 a las 19:30, Thibault Vatter > () escribió: > > > > Dear package developers, > > > > We've recently received an email letting us know that our package > > rvinecopulib ( > > https://cran.r-project.org/web/packages/rvinecopulib/index.html) would > be > > removed from CRAN unless the errors from the solaris build were > corrected. > > > > Note that the package compile and the unit tests pass on the other test > > platforms from CRAN and even a local R devel build with ASAN / UBSAN > > sanitizers. On solaris, the package compiles but a segfault is produced > by > > one unit test for a reason that we still don't understand. > > Are you talking about a new development version that is not still on > CRAN? Because the current CRAN version fails to install. > > Iñaki > > > > > To replicate the issue, I tried to mimic CRAN's solaris config ( > > https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86) in a > > virtual machine following the steps in the gist below (based on > Jeroen's): > > > > https://gist.github.com/tvatter/b2503f03fcd604ff764ffe4b979afcb6 > > > > Note that the "--with-readline=no" configure option at the end was added > > because I got "configure: error: --with-readline=yes (default) and > > headers/libs are not available" without it. > > > > Unfortunately, I then got the "configure: error: a suitable iconv is > > essential" and could not proceed to build R. > > > > I know that I should get GNU iconv as specified in the installation > manual, > > hence the "/opt/csw/bin/pkgutil -y -i libiconv_dev" in the gist above. I > > verified that iconv is in /opt/csw/lib as expected and I thought that > > adding /opt/csw/lib to R_LD_LIBRARY_PATH as suggested in the manual would > > then do the trick, but it does not seem to be the case. > > > > Two questions: > > > > 1) What did I miss or do wrong? > > > > 2) Anyone found a way to replicate solaris CRAN builds to test packages? > I > > tried to use https://builder.r-hub.io/, but some of my package's > > dependencies fail to install because of udunits2 is missing on their > system > > if I recall correctly. > > > > Thibault > > > > [[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
[R-pkg-devel] Replicate solaris errors
Dear package developers, We've recently received an email letting us know that our package rvinecopulib ( https://cran.r-project.org/web/packages/rvinecopulib/index.html) would be removed from CRAN unless the errors from the solaris build were corrected. Note that the package compile and the unit tests pass on the other test platforms from CRAN and even a local R devel build with ASAN / UBSAN sanitizers. On solaris, the package compiles but a segfault is produced by one unit test for a reason that we still don't understand. To replicate the issue, I tried to mimic CRAN's solaris config ( https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86) in a virtual machine following the steps in the gist below (based on Jeroen's): https://gist.github.com/tvatter/b2503f03fcd604ff764ffe4b979afcb6 Note that the "--with-readline=no" configure option at the end was added because I got "configure: error: --with-readline=yes (default) and headers/libs are not available" without it. Unfortunately, I then got the "configure: error: a suitable iconv is essential" and could not proceed to build R. I know that I should get GNU iconv as specified in the installation manual, hence the "/opt/csw/bin/pkgutil -y -i libiconv_dev" in the gist above. I verified that iconv is in /opt/csw/lib as expected and I thought that adding /opt/csw/lib to R_LD_LIBRARY_PATH as suggested in the manual would then do the trick, but it does not seem to be the case. Two questions: 1) What did I miss or do wrong? 2) Anyone found a way to replicate solaris CRAN builds to test packages? I tried to use https://builder.r-hub.io/, but some of my package's dependencies fail to install because of udunits2 is missing on their system if I recall correctly. Thibault [[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] Portable method of stripping debug symbols
No, we're preparing a new release which we'll submit in the next few days. On Thu, Jan 4, 2018 at 7:06 PM, Dirk Eddelbuettel wrote: > > On 4 January 2018 at 00:27, Thibault Vatter wrote: > | We faced a problem when we tried Dirk's solution for our package > | rvinecopulib: there is a strip binary on OS X but it doesn't work as the > | linux one. > | > | As such, to avoid calling OS X's strip which doesn't work, we use: > | > | strippedLib: $(SHLIB) > | if test -e "/usr/bin/strip" & test -e "/bin/uname" & [[ `uname` == > "Linux" > | ]] ; then /usr/bin/strip --strip-debug $(SHLIB); fi > | .phony: strippedLib > > Yes, this is good. Someone (you?) had pointed this out to me before. > > Did you add this to your actual released and on-CRAN package? > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > [[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] Portable method of stripping debug symbols
Hi, We faced a problem when we tried Dirk's solution for our package rvinecopulib: there is a strip binary on OS X but it doesn't work as the linux one. As such, to avoid calling OS X's strip which doesn't work, we use: strippedLib: $(SHLIB) if test -e "/usr/bin/strip" & test -e "/bin/uname" & [[ `uname` == "Linux" ]] ; then /usr/bin/strip --strip-debug $(SHLIB); fi .phony: strippedLib Hope this helps, Thibault On Wed, Jan 3, 2018 at 11:13 PM, Dirk Eddelbuettel wrote: > > Christopher, > > On 3 January 2018 at 21:59, Christopher Lalansingh wrote: > | I'm running into troubles with the total size of my package and I've > found that when using Rcpp, one can reduce the size of shared objects by > stripping out debug symbols by including `-Wl,-S' in PKG_LIBS. > Unfortunately this is not portable with Solaris, and using ifeq in my > Makevars file to check for SunOS isn't portable either. > | > | I came across an Issue on github (https://github.com/RcppCore/ > Rcpp/issues/522) which addresses possible ways to do this portably, but I > can't find reference to // [[Rcpp::plugins(strip)]] in any other > documentation. If anyone has run into this before and has any suggestions > it would be much appreciated. > > I have two writeups on this in my r^4 series: > > http://dirk.eddelbuettel.com/blog/2017/08/20#010_stripping_ > shared_libraries > http://dirk.eddelbuettel.com/blog/2017/08/14#009_compact_shared_libraries > > The earlier one has this snippet you can add to src/Makevars, and you could > even do this conditionally (ie do it on Linux, don't do it on Solaris, or > the > other way, or ...) > > strippedLib: $(SHLIB) > if test -e "/usr/bin/strip"; then /usr/bin/strip --strip-debug > $(SHLIB); fi > > .phony: strippedLib > > This will strip if and only if there is a strip binary. May work for yuo. > > Dirk > > -- > 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 > [[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] Proper way to cleanup after build third party components?
Hi Konstantin, Concerning CMake, I asked a similar question here: https://stat.ethz.ch/pipermail/r-package-devel/2017q2/001600.html Essentially, I wondered if there was a way to have CMake within an R package, but obviously having a system install of CMake would work in my case too. Hopefully answers to your question will be more useful than answers to mine ;) On Mon, Jun 5, 2017 at 5:29 AM, Konstantin Sorokin wrote: > On Mon, Jun 5, 2017 at 1:13 AM, Dirk Eddelbuettel wrote: > > > > > On 5 June 2017 at 00:51, Konstantin Sorokin wrote: > > | This third party component is a compression library for which my > package > > | provides bindings and I need to build this library first. Look at the > > lines > > | starting from > > | https://github.com/thekvs/zstdr/blob/8ea428b33d986667494d940c66732d > > bbc66871b3/configure.ac#L34 > > > > The common paradigm is to first build below src/, and to then link via > > src/Makevars to the static library you just built. > > > > I don't have a real go-to example of a package that does this but you > could > > look into the BioConductor package RGBL (which builds Boost Graph first) > > and/or the nloptr package (which, if need be, downloads nlopt and builds > > it; > > my contribution there was the other part of finding / using a libnlopt if > > on > > the system). > > > > Thanks, Dirk, I'll look at nloptr package more closely. > > > > > > I wondered about this when CRANberries told me about your package. I > guess > > you can't assume the Zstandard library to be present? Maybe one day the > > hybrid approach of nloptr may work for you. > > > > zstandard is a young project and I think it is a bit to early to assume > that zstandard library be present in the system. For example on my Ubuntu > 16.04 (LTS) I have libzstd0/xenial 0.5.1-1 but the latest stable release > has version 1.2. > > Btw, what about installing cmake on OSX and Solaris in CRAN build farm? Now > it is such a ubiquitous and widely used program! > > -- > Konstantin Sorokin > > [[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] CRAN and cmake
My bad, my question was not precise enough: by "an R package containing
cmake", I meant "an R package containing cmake itself" in order to be able
to use cmake e.g. when building an R package from source.
A little bit of context: I am trying to write an R interface to a C++
library where cmake was used instead of autotools, I would like my
configure.ac file to contain something like:
$("${R_HOME}/bin/Rscript download.file(url='${LIBRARY_URL}',
destfile='${LIBRARY_TGZ}')")
$("${R_HOME}/bin/Rscript untar(tarfile='${LIBRARY_TGZ}')")
$("${R_HOME}/bin/Rscript cmake('LIBRARY/CMakeLists.txt')")
In https://github.com/stnava/cmaker/issues/2, it was mentioned that the
cmaker package was refused from CRAN mostly because of a cross-platform
issue (mostly windows portability).
Concerning the cross-platform issue for windows, Gabor suggested to
"download [the cmake binaries] at install time, like the rest of the
rwinlib stuff".
Therefore, I wonder whether it would be wort trying to work on an updated
version of cmaker or if this is indeed "dead in the water".
Best,
Thibault
On Tue, May 23, 2017 at 11:56 AM, Dirk Eddelbuettel wrote:
>
> On 23 May 2017 at 10:34, Thibault Vatter wrote:
> | Hi,
> |
> | Back in 2015, there was a discussion on this list about CRAN and cmake.
> |
> | As explained by Gabor at the time, it would be useful to have cmake in a
> R
> | package.
> |
> | Furthermore, Gregory mentioned that there was something available on
> GitHub:
> |
> | https://github.com/stnava/cmaker
> |
> | Since it seems that the package was CRAN-ready two years ago, I wondered
> | what happened?
> |
> | Would an R package containing cmake be accepted in CRAN?
>
> Yes. Many of them do.
>
> A nice benefit of Gabor's CRAN mirror on GitHub is access to the GitHub.
> Here I constrain on user:cran (to get just that mirror, and nothing) and
> CMakeLists.txt. Seems to find 47 repos -- corresponding to 47 packages.
>
> https://github.com/search?q=user%3Acran+CMakeLists.txt&type=
> Code&utf8=%E2%9C%93
>
> Hth, Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] CRAN and cmake
Hi, Back in 2015, there was a discussion on this list about CRAN and cmake. As explained by Gabor at the time, it would be useful to have cmake in a R package. Furthermore, Gregory mentioned that there was something available on GitHub: https://github.com/stnava/cmaker Since it seems that the package was CRAN-ready two years ago, I wondered what happened? Would an R package containing cmake be accepted in CRAN? Best, Thibault [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
