[R-pkg-devel] Replicate solaris errors

[Thibault Vatter]

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 using gmail.com> wrote:

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

	[[alternative HTML version deleted]]