[R] Package installation help: Stuck at "** byte-compile and prepare package for lazy loading"

[Bill Dunlap]

You can define the environment variable R_DONT_USE_TK (to any value) to
avoid this hang caused by code in the tkrplot package.  You do not have to
have an X server running if R_DONT_USE_TK is set.  This will avoid
potential hangs while installing the 23 packages that depend on tkrplot.

tools::package_dependencies("tkrplot", reverse=TRUE, recursive=TRUE)
$tkrplot
 [1] "adoption"               "baggingbwsel"           "biplotbootGUI"
 [4] "cncaGUI"                "ConvergenceConcepts"    "fisheyeR"
 [7] "forensim"               "GGEBiplotGUI"           "GUIDE"
[10] "idendr0"                "InterfaceqPCR"          "multibiplotGUI"
[13] "RclusTool"              "RcmdrPlugin.FuzzyClust"
"RcmdrPlugin.PcaRobust"
[16] "rriskDistributions"     "RVideoPoker"            "SyNet"
[19] "tsgui"                  "uHMM"                   "GGEBiplots"
[22] "decisionSupport"        "geneticae"

E.g.,

> install.packages("forensim", type="source",
INSTALL_opts="--no-byte-compile")
Installing package into ‘/home/bill/R-devel/R-build/site-library’
(as ‘lib’ is unspecified)
trying URL 'https://cloud.r-project.org/src/contrib/forensim_4.3.tar.gz'
Content type 'application/x-gzip' length 84232 bytes (82 KB)
==================================================
downloaded 82 KB

* installing *source* package ‘forensim’ ...
** package ‘forensim’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
gcc -I"/home/bill/R-devel/R-build/include" -DNDEBUG   -I/usr/local/include
  -fpic  -g  -c auxilary.c -o auxilary.o
gcc -I"/home/bill/R-devel/R-build/include" -DNDEBUG   -I/usr/local/include
  -fpic  -g  -c recursFinal.c -o recursFinal.o
gcc -shared -L/usr/local/lib -o forensim.so auxilary.o recursFinal.o
installing to
/home/bill/R-devel/R-build/site-library/00LOCK-forensim/00new/forensim/libs
** R
** data
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location
** checking absolute paths in shared objects and dynamic libraries
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation
path
* DONE (forensim)

The downloaded source packages are in
        ‘/tmp/Rtmp0jqhj9/downloaded_packages’

The relevant code is in tkrplot/src/tcltkimg.c:

EXPORT(int,Rplot_Init)(interp)
    Tcl_Interp *interp;
{
    /* Added to allow CRAN to disable Tk initialization */
#if !defined(Win32) && !defined(HAVE_AQUA)
    if (getenv("R_DONT_USE_TK") != NULL)
        return 0;
#endif

-Bill


On Thu, Sep 30, 2021 at 9:35 AM Brodie, Kent <brodie using mcw.edu> wrote:

> Bill--   BINGO.    You have found the answer.     After some testing on
> one of my environments where it was always hanging, connecting to the same
> server with an X-Sever running on my workstation did indeed allow the
> package to be installed.
>
>
>
> **GOOD LORD THAT’S RIDICULOUS**   But---- at least I know.    And why it
> doesn’t error out without X running, who knows.
>
>
>
> After a ton more research, I ALSO discovered that there IS a timeout thing
> I can make use of, should I decide to continue just building things and
> ignoring the X-Server requirement for this (and probably some other?)
> packages.
>
>
>
> Before executing R and installing things, set this:
>
>
>
> export _R_INSTALL_PACKAGES_ELAPSED_TIMEOUT_=500
>
>
>
> (value is seconds).   So, the previously-hanging R CMD INSTALL inside of
> the install.packages call will eventually die, and then move on to the next
> package.
>
> This is buried in the documentation but- it’s there and I confirmed it
> works.    My example above times out a package install  at 5 minutes.
>
>
>
> While knowing the X requirement is a huge win (thanks again!), I will
> probably stick with just using the timeout thing for what I’m trying to
> accomplish.    Installing EVERYTHING from cran will take forever, and more
> than likely my VPN connection to my data center will be disconnected (thank
> you internal IT department) before it finishes.    They have some sort of
> internal “you’ve been connected too long” timer that disconnects things
> overnight.   Grr.
>
>
>

	[[alternative HTML version deleted]]