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.uca...@gmail.com> wrote: > El sáb., 11 ago. 2018 a las 20:41, Thibault Vatter > (<thibault.vat...@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.uca...@gmail.com> wrote: > >> > >> El sáb., 11 ago. 2018 a las 19:30, Thibault Vatter > >> (<thibault.vat...@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@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