WIP: [ci] use R 4.2 in Windows R-package CI jobs (fixes #4881)

[jameslamb]

Fixes #4881.

Attempts to add support for R 4.2 in most of the R package's CI jobs.

Notes for Reviewers

#4881 refers to creating a comment-triggered workflow for the UCRT toolchain for Windows builds, but I don't think that's necessary any more now that R 4.2.0 has actually been released and Rtools42 contains the UCRT build tools.

References for some concerns about Windows builds:

• Rtools42
  • https://cran.r-project.org/bin/windows/Rtools/rtools42/rtools.html
• CRAN still requires 32-bit builds for r-oldrel (which is R 4.1)
  • https://cran.r-project.org/web/checks/check_flavors.html#r-devel-windows-x86_64
• different paths for different versions, per r-lib/actions code
  • https://github.com/r-lib/actions/blob/8e8f7edba0e5bda9318f9377c0dc9c2f5d0fb786/setup-r/src/installer.ts#L431-L457

References

r-lib/actions#574 (comment)

https://cran.r-project.org/bin/windows/base/howto-R-4.2.html

To make the use of Rtools42 simpler, when R is installed via the binary installer it by default uses Rtools42 for the compilers and libraries. PATH will be set by R (inside front-ends like RGui and RTerm, but also R CMD) to include the build tools (e.g. make) and the compilers (e.g. gcc). In addition, R installed via the binary installer will automatically set R_TOOLS_SOFT (and LOCAL_SOFT for backwards compatibility) to the Rtools42 location for building R packages. This feature is only present in the installer builds of R, not when R is installed from source.

Related fix in r-lib/actions: r-lib/actions@7d98418

[StrikerRUS]

I'd like to propose checking passed R version to the FindLibR.cmake module from the logs

LightGBM/cmake/modules/FindLibR.cmake

Line 76 in f1328d5

message(STATUS "R version passed into FindLibR.cmake: ${CMAKE_R_VERSION}")

similarly to

LightGBM/.ci/test_r_package.sh

Lines 237 to 253 in f1328d5

	# this check makes sure that CI builds of the package
	# actually use MM_PREFETCH preprocessor definition
	if [[ $R_BUILD_TYPE == "cran" ]]; then
	mm_prefetch_working=$(
	cat $BUILD_LOG_FILE \
	| grep --count -E "checking whether MM_PREFETCH work.*yes"
	)
	else
	mm_prefetch_working=$(
	cat $BUILD_LOG_FILE \
	| grep --count -E ".*Performing Test MM_PREFETCH - Success"
	)
	fi
	if [[ $mm_prefetch_working -ne 1 ]]; then
	echo "MM_PREFETCH test was not passed"
	exit -1
	fi

That will prevent situations like #5129 (comment).

[jameslamb]

ooooo, I think that the inet_pton detection check in configure.win might be part of the problem!

I tried running the following shell script in the CI builds for the Windows jobs.

echo "------ testing test program ----"

cat > conftest.cpp <<EOL
#include <ws2tcpip.h>
int main() {
  void* p = inet_pton;
  return 0;
}
EOL

g++ -std=gnu++11 -I"c:/rtools42/x86_64-w64-mingw32.static.posix/include" -o conftest conftest.cpp || exit 123
echo "------ done compiling ----"

./conftest || exit 123
rm -f ./conftest
rm -f ./conftest.cpp
echo "------ done running ----"

And got the following

------ testing test program ----
conftest.cpp: In function 'int main()':
conftest.cpp:3:13: error: invalid conversion from 'INT (*)(INT, LPCSTR, PVOID)' {aka 'int (*)(int, const char*, void*)'} to 'void*' [-fpermissive]
    3 |   void* p = inet_pton;
      |             ^~~~~~~~~
      |             |
      |             INT (*)(INT, LPCSTR, PVOID) {aka int (*)(int, const char*, void*)}
Building R package

To me, that looks like inet_pton was FOUND, but was incorrectly detected as NOT FOUND because this code can't be compiled.

[jameslamb]

This also seems relevant for the CMake side: https://cmake.org/cmake/help/latest/module/CheckCXXSymbolExists.html

CheckCXXSymbolExists command is unreliable when is (potentially) an overloaded function. Since there is no reliable way to predict whether a given function in the system environment may be defined as an overloaded function or may be an overloaded function on other systems or will become so in the future, it is generally advised to use the CheckCXXSourceCompiles module for checking any function symbol (unless somehow you surely know the checked function is not overloaded on other systems or will not be so in the future).

[jameslamb]

Closing this in favor of #5503 , which includes the fixes discovered through this investigation.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.