[Rd] Error compiling 87283 on Windows 10 using Rtools4.4 6335-6327

[Avraham Adler]

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.kalibera using gmail.com> wrote:
>
>
> On 10/31/24 18:35, Avraham Adler wrote:
> > On Thu, Oct 31, 2024 at 12:42 PM Tomas Kalibera
> > <tomas.kalibera using 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 using r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel