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.
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:/PROGRA
1/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:
@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.