For (temporary) closure. The error only manifests if OpenBLAS is built with the setting "INTERFACE64=1" in Makefile.rule, whose explanation is: "If you want to drive whole 64bit region by BLAS. Not all Fortran # compilers support this. It's safe to keep this commented out if you # are not sure. (This is equivalent to the "-i8" ifort option)."
When this setting is commented out, R compiles and passes check-devel. Why setting this creates a segfault when byte-compiling grDevices is well beyond my ken, but for now, so long as "INTERFACE64=1" is commented out, R should compile with OpenBLAS completely as it has for the past decade or two (adjusting for the recent change in src/extra/blas/Makefile.win, of course) Thank you, especially Tomas! Avi On Thu, Oct 31, 2024 at 2:06 PM Tomas Kalibera <tomas.kalib...@gmail.com> wrote: > > > On 10/31/24 18:35, Avraham Adler wrote: > > On Thu, Oct 31, 2024 at 12:42 PM Tomas Kalibera > > <tomas.kalib...@gmail.com> wrote: > >> On 10/31/24 17:30, Avraham Adler wrote: > >>> When compiling R, the build fails after byte compiling grDevices with > >>> the following error: > >>> > >>> byte-compiling package 'grDevices' > >>> make[4]: *** [../../../share/make/lazycomp.mk:9: > >>> ../../../library/grDevices/R/grDevices.rdb] Error 139 > >>> make[3]: *** [Makefile.win:23: all] Error 2 > >>> make[2]: *** [Makefile.win:34: R] Error 1 > >>> make[1]: *** [Makefile:18: all] Error 2 > >>> make: *** [Makefile:392: distribution] Error 2 > >>> > >>> I restarted the build, as sometimes that allows it to power through, > >>> but it failed at the same point. Any thoughts or suggestions would be > >>> appreciated. > >> Dear Avi, > >> > >> could you please post which compile options are you using? The vanilla > >> builds with default options are being tested regularly (and work). > >> > >> Best > >> Tomas > > Thank you, Tomas. Of course. > > > > Mkrules.local: > > USE_ATLAS = YES > > ATLAS_PATH = C:/R/OPB/OpenBLAS-0.3.28-5ef8b19 > > EOPTS = -march=native -pipe -mno-rtm -Wa,-muse-unaligned-vector-move > > LTO = -flto=1 -fuse-linker-plugin > > LTO_OPT = -flto=1 -fuse-linker-plugin > > LTO_FC = -flto=1 -fuse-linker-plugin > > LTO_FC_OPT = -flto=1 -fuse-linker-plugin > > QPDF = C:/R/qpdf-11.9.1-msvc64 > > OPENMP = -fopenmp > > > > And, of course, blas/Makefiles.win has been patched to read the proper > > library, which I've been doing for over a decade. > > Ok, could you please try the very same build (so the same version of R, > same options, same external libs) with the previous version of Rtools44? > Does that pass? > > Thanks > Tomas > > > > > Thank you again! > > > >>> This may be unrelated, but as I was monitoring the compilation, I saw > >>> an warning which I haven't seen before in the 20 or so years I've been > >>> building R on Windows: > >>> > >>> In function 'R_chk_memset', > >>> inlined from 'do_aperm' at ../main/array.c:1754:5: > >>> ../main/memory.c:3578:16: warning: 'memset' specified bound between > >>> 18446744056529682432 and 18446744073709551608 exceeds maximum object > >>> size 9223372036854775807 [-Wstringop-overflow=] > >>> 3578 | return n ? memset(s, c, n) : s; > >>> | > >>> > >>> No idea if it is related but I thought I should mention it. > >>> Thank you, > >>> > >>> Avi > >>> > >>> ______________________________________________ > >>> R-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
