Skip to content

[BUG] Build failure installing pak v0.11.0 (Windows/R 4.6/rtools45) #898

Open

Description

@jkylearmstrong

pak_install_error.txt

See full error log.

Title: [BUG] Build failure installing pak v0.11.0 (Windows/R 4.6/rtools45) - Log truncated
Environment:

OS: Windows (x86_64-w64-mingw32)
R Version: R 4.6.0 (C:/PROGRA1/R/R-461.0)
Toolchain: rtools45 (GCC 14.3.0)
Package: pak version 0.11.0 (installed via renv)
Description:
Attempting to install the pak package from source fails during the compilation of its bundled dependencies. The build process successfully compiles R6, cli, curl, filelock, and jsonlite, but the provided error log cuts off abruptly while compiling the lpSolve dependency, hiding the actual fatal error.

Observed Warnings in Log:
While these may not be the root cause, the build generates a high volume of compiler warnings with the new GCC 14.3.0 toolchain:

lpSolve (C code): Dozens of -Wmaybe-uninitialized, -Wunused-but-set-variable, and -Wmisleading-indentation warnings. (e.g., in hbio.c, lp_MPS.c, lp_presolve.c, sparselib.c).
jsonlite (R code): Missing S4 method definitions for classes like "AsIs", "ITime", "hms", "integer64", and "sf". This is likely benign and just indicates missing suggested packages, but worth noting.
cli (C code): Uninitialized variable warning in diff.c.
Steps to Reproduce:

Open R 4.6.0 on Windows with rtools45 active.
Run renv::restore() (or equivalent command) that triggers a from-source installation of pak 0.11.0.
Observe the build failure.
Expected Behavior:
pak and its bundled dependencies compile cleanly and install successfully.

Actual Behavior:
Installation halts. The log ends exactly here:

gcc  -I"C:/PROGRA~1/R/R-46~1.0/include" -DNDEBUG -I . -DINTEGERTIME ... -c sparselib.c -o sparselib.o
sparselib.c: In function 'dswapVector1':
sparselib.c:823:10: warning: variable 'd' set but not used [-Wunused-but-set-variable]
  823 |   int i, d, n;
      |          ^
[...]
Action Required / Next Steps:

@reporter: Please provide the tail end of the build log (the lines immediately following [...] in your text file). The fatal error (e.g., a missing header, a linking error, or an actual compiler error -Werror) is required to diagnose the root cause.
Hypothesis: Given the strictness of GCC 14, it is possible that a downstream compiler flag is treating one of the many lpSolve warnings as a fatal error, or there is a missing library dependency for lpSolve that hasn't been reached yet in the log output.

Activity

  1. changed the title [-]install error[/-] [+][BUG] Build failure installing pak v0.11.0 (Windows/R 4.6/rtools45)[/+] on Jul 16, 2026
  2. gaborcsardi commented on Jul 16, 2026

    @gaborcsardi
    Member

    This is the real error, from the end of the log:

    ** testing if installed package can be loaded from temporary location
    Warning in file.rename(instdir, final_instdir) :
      cannot rename file 'C:/Users/jkyle/Documents/GitHub/pslongsim/renv/staging/8/00LOCK-pak/00new/pak' to 'C:/Users/jkyle/Documents/GitHub/pslongsim/renv/staging/8/pak', reason 'Access is denied'
    ERROR:    moving to final location failed
    * removing 'C:/Users/jkyle/Documents/GitHub/pslongsim/renv/staging/8/pak'
    install of package 'pak' failed [error code 1]
    

    If this fails for you with install.packages("pak", type = "source"), then it is almost certainly an issue with your configuration, because I can't reproduce it on two windows machines, on GitHub Actions, and CRAN also cannot reproduce it.

    I did not try renv, because you didn't include the steps to reproduce it with renv. I.e. I don't have your log file.

    Maybe you have the pak package loaded in another R session while you are trying to install it.

    If it only fails in renv, then please provide a reproducible example with renv, and/or try to ask https://forum.posit.co/ with the 'renv' tag.

    Please provide the tail end of the build log (the lines immediately following [...] in your text file). The fatal error (e.g., a missing header, a linking error, or an actual compiler error -Werror) is required to diagnose the root cause. Hypothesis: Given the strictness of GCC 14, it is possible that a downstream compiler flag is treating one of the many lpSolve warnings as a fatal error, or there is a missing library dependency for lpSolve that hasn't been reached yet in the log output.

    This is AI nonsense. Do not post AI "hypothesis" without actually checking it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions