Bug: Broken installation of source packages on AppVeyor
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 09/Oct/20 22:30
Affects Version/s: 3.1.0

It looks like AppVeyor configuration is broken, which leads to failure of installation of  source packages (become a problem when {{rlang}} has been updated from 0.4.7 and 0.4.8, with latter available only as a source package).

{code}

[00:01:48] trying URL
'https://cloud.r-project.org/src/contrib/rlang_0.4.8.tar.gz'
[00:01:48] Content type 'application/x-gzip' length 847517 bytes (827 KB)
[00:01:48] ==================================================
[00:01:48] downloaded 827 KB
[00:01:48] 
[00:01:48] Warning in strptime(xx, f, tz = tz) :
[00:01:48]   unable to identify current timezone 'C':
[00:01:48] please set environment variable 'TZ'
[00:01:49] * installing *source* package 'rlang' ...
[00:01:49] ** package 'rlang' successfully unpacked and MD5 sums checked
[00:01:49] ** using staged installation
[00:01:49] ** libs
[00:01:49] 
[00:01:49] *** arch - i386
[00:01:49] C:/Rtools40/mingw64/bin/gcc  -I"C:/R/include" -DNDEBUG
-I./lib/         -O2 -Wall  -std=gnu99 -mfpmath=sse -msse2
-mstackrealign -c capture.c -o capture.o
[00:01:49] C:/Rtools40/mingw64/bin/gcc  -I"C:/R/include" -DNDEBUG
-I./lib/         -O2 -Wall  -std=gnu99 -mfpmath=sse -msse2
-mstackrealign -c export.c -o export.o
[00:01:49] C:/Rtools40/mingw64/bin/gcc  -I"C:/R/include" -DNDEBUG
-I./lib/         -O2 -Wall  -std=gnu99 -mfpmath=sse -msse2
-mstackrealign -c internal.c -o internal.o
[00:01:50] In file included from ./lib/rlang.h:74,
[00:01:50]                  from internal/arg.c:1,
[00:01:50]                  from internal.c:1:
[00:01:50] internal/eval-tidy.c: In function 'rlang_tilde_eval':
[00:01:50] ./lib/env.h:33:10: warning: 'top' may be used uninitialized
in this function [-Wmaybe-uninitialized]
[00:01:50]    return ENCLOS(env);
[00:01:50]           ^~~~~~~~~~~
[00:01:50] In file included from internal.c:8:
[00:01:50] internal/eval-tidy.c:406:9: note: 'top' was declared here
[00:01:50]    sexp* top;
[00:01:50]          ^~~
[00:01:50] C:/Rtools40/mingw64/bin/gcc  -I"C:/R/include" -DNDEBUG
-I./lib/         -O2 -Wall  -std=gnu99 -mfpmath=sse -msse2
-mstackrealign -c lib.c -o lib.o
[00:01:51] C:/Rtools40/mingw64/bin/gcc  -I"C:/R/include" -DNDEBUG
-I./lib/         -O2 -Wall  -std=gnu99 -mfpmath=sse -msse2
-mstackrealign -c version.c -o version.o
[00:01:52] C:/Rtools40/mingw64/bin/gcc -shared -s -static-libgcc -o
rlang.dll tmp.def capture.o export.o internal.o lib.o version.o
-LC:/R/bin/i386 -lR
[00:01:52]
c:/Rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
skipping incompatible C:/R/bin/i386/R.dll when searching for -lR
[00:01:52]
c:/Rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
skipping incompatible C:/R/bin/i386/R.dll when searching for -lR
[00:01:52]
c:/Rtools40/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
cannot find -lR
[00:01:52] collect2.exe: error: ld returned 1 exit status
[00:01:52] no DLL was created
[00:01:52] ERROR: compilation failed for package 'rlang'
[00:01:52] * removing 'C:/RLibrary/rlang'
[00:01:52] 
[00:01:52] The downloaded source packages are in
[00:01:52]    
'C:\Users\appveyor\AppData\Local\Temp\1\Rtmp8qrryA\downloaded_packages'
[00:01:52] Warning message:
[00:01:52] In install.packages(c("knitr", "rmarkdown", "testthat",
"e1071",  :
[00:01:52]   installation of package 'rlang' had non-zero exit status 
{code}

This leads to failures to install {{devtools}} and generate Rd files and, as a result, CRAN check failure.

There are some discrepancies in the {{dev/appveyor-install-dependencies.ps1}}, but the direct source of this issue seems to be {{$env:BINPREF}}, which forces usage of 64 bit mingw, even if packages are compiled for 32 bit. 

Modifying the variable to include current architecture:

{code}
$env:BINPREF=$RtoolsDrive + '/Rtools40/mingw$(WIN)/bin/'
{code}

(as proposed [here|https://stackoverflow.com/a/44035904] by R Yoda) looks like a valid fix, though we might want to clean remaining issues as well.