[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 <i.ucar86 at gmail.com> wrote:
El s?b., 11 ago. 2018 a las 20:41, Thibault Vatter (<thibault.vatter at gmail.com>) 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 <i.ucar86 at gmail.com> wrote:
El s?b., 11 ago. 2018 a las 19:30, Thibault Vatter (<thibault.vatter at gmail.com>) 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 at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel