Re: [R] Compilation problems with R4.4.0
Glad you got R working! В Thu, 9 May 2024 12:19:49 + Simon Andrews пишет: > Does this need reporting upstream as a bug in R or lapack? Maybe in AlmaLinux (and I think RHEL9 too, but that's up to Miguel Esteva). Best case scenario, they somehow built the reference BLAS and LAPACK packages with the wrong Fortran compiler version or flags, which is why gfortran-11 gets a zero instead of the return value from DOUBLE COMPLEX zdotu(...) and crashes when calling dgesv(...) from lapack-3.9.0-10.el9.x86_64. Worst case scenario, the zdotu() problem and the crash have two completely different causes elsewhere. -- Best regards, Ivan __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Compilation problems with R4.4.0
Thank you! Installing openblas and then using ./configure --without-lapack --with-blas --enable-R-shlib ..got everything working. Does this need reporting upstream as a bug in R or lapack? I'm good now, but it might help others to get this fixed. Simon. -Original Message- From: Ivan Krylov Sent: 08 May 2024 20:05 To: Simon Andrews Cc: Simon Andrews via R-help ; Miguel Esteva Subject: Re: [R] Compilation problems with R4.4.0 В Wed, 8 May 2024 16:59:25 + Simon Andrews пишет: > The lapack libraries are: > > $ rpm -qa | grep lapack > lapack-3.9.0-10.el9.x86_64 > lapack64_-3.9.0-10.el9.x86_64 > lapack64-3.9.0-10.el9.x86_64 > lapack-devel-3.9.0-10.el9.x86_64 Thanks for this information! I figured out I needed to enable the "PowerTools/CRB" repo, installed lapack-devel from there, and now I get the same configure output and the same crash: by linking with R's built-in Rblas but and system-provided LAPACK-3.9.0. If I configure --without-lapack, i.e. use both Rblas and R-provided functions from LAPACK up to 3.12.0, the build doesn't crash. If I try to enable --with-blas=-lblas, here's what happens: configure:47862: checking whether double complex BLAS can be used configure:47946: result: no The test compares the result of the BLAS function zdotu with the manually computed vector norm for a complex vector [*]. In this case, the Fortran program thinks that the BLAS returns a zero instead of the correct answer, thus failing the test and refusing to compile with system BLAS. I think that you somehow stumbled upon a Fortran ABI incompatibility regarding passing complex numbers between the Fortran code compiled during R build and the BLAS and LAPACK provided in the PowerTools/CRB repo. I don't know what exactly is the problem, but at least --without-lapack is an easy workaround without any cost in performance. In fact, if you install openblas-devel and configure --with-blas (to replace Rblas with OpenBLAS), the double complex BLAS test will pass, the build won't crash, and you will get even better performance. -- Best regards, Ivan [*] https://stat.ethz.ch/pipermail/r-devel/2024-March/083302.html This email has been scanned for spam & viruses. If you believe this email should have been stopped by our filters, click the following link to report it (https://portal-uk.mailanyone.net/index.html#/outer/reportspam?token=dXNlcj1zaW1vbi5hbmRyZXdzQGJhYnJhaGFtLmFjLnVrO3RzPTE3MTUxOTUxMjQ7dXVpZD02NjNCQ0NGMzA1RDJGMzA3RDhDMjIxQTZCRUE3MEQ3MDt0b2tlbj0yZTdkOWY0ZjNjZmQ2NGQyZGFlMmYwZjQ2MTk5NjdmODk2ZDM3YjQyOw%3D%3D). __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Compilation problems with R4.4.0
В Wed, 8 May 2024 16:59:25 + Simon Andrews пишет: > The lapack libraries are: > > $ rpm -qa | grep lapack > lapack-3.9.0-10.el9.x86_64 > lapack64_-3.9.0-10.el9.x86_64 > lapack64-3.9.0-10.el9.x86_64 > lapack-devel-3.9.0-10.el9.x86_64 Thanks for this information! I figured out I needed to enable the "PowerTools/CRB" repo, installed lapack-devel from there, and now I get the same configure output and the same crash: by linking with R's built-in Rblas but and system-provided LAPACK-3.9.0. If I configure --without-lapack, i.e. use both Rblas and R-provided functions from LAPACK up to 3.12.0, the build doesn't crash. If I try to enable --with-blas=-lblas, here's what happens: configure:47862: checking whether double complex BLAS can be used configure:47946: result: no The test compares the result of the BLAS function zdotu with the manually computed vector norm for a complex vector [*]. In this case, the Fortran program thinks that the BLAS returns a zero instead of the correct answer, thus failing the test and refusing to compile with system BLAS. I think that you somehow stumbled upon a Fortran ABI incompatibility regarding passing complex numbers between the Fortran code compiled during R build and the BLAS and LAPACK provided in the PowerTools/CRB repo. I don't know what exactly is the problem, but at least --without-lapack is an easy workaround without any cost in performance. In fact, if you install openblas-devel and configure --with-blas (to replace Rblas with OpenBLAS), the double complex BLAS test will pass, the build won't crash, and you will get even better performance. -- Best regards, Ivan [*] https://stat.ethz.ch/pipermail/r-devel/2024-March/083302.html __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Compilation problems with R4.4.0
Also just did a full errata update and retried the compilation. It failed exactly as before. -Original Message- From: Ivan Krylov Sent: 08 May 2024 16:09 To: Simon Andrews Cc: Simon Andrews via R-help ; Miguel Esteva Subject: Re: [R] Compilation problems with R4.4.0 В Wed, 8 May 2024 14:25:08 + Simon Andrews пишет: > #8 0x73f87c0b in dgesv ( > n=12884901891, nrhs=4294967299, > a=, > lda=12884901891, ipiv=..., b= optimized out>, ldb=12884901891, info=0 > ) at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgesv.f:167 > #9 0x750b2a17 in La_solve ( > tolin=, Bin=, A=0x18f2f68 > ) at Lapack.c:1246 > #10 mod_do_lapack ( > call=, op=, args=, > env= > ) at Lapack.c:1483 It looks like this R build is linked to a LAPACK. I now also notice LAPACK(generic) in the list of external libraries in your ./configure output. I've tried to link R to AlmaLinux's builds of reference BLAS and LAPACK using --with-blas='-l:libblas.so.3' --with-lapack='-l:liblapack.so.3' (where do I get libblas.so on AlmaLinux?), but that doesn't crash either. What does the config.log currently say about your BLAS and LAPACK situation? It's a number of lines between configure:47012: checking whether 'struct tm' includes tm_gmtoff and configure:48858: checking for iconv.h. If you'd like to link your R to custom BLAS and LAPACK, try specifying the necessary linker flags explicitly with --with-blas=-lwhatever, --with-lapack=-lwhatever. If you're fine with reference BLAS & LAPACK that come with R, try ./configure --without-blas --without-lapack. Normally, R's ./configure tries to prevent linking to an external LAPACK without linking to an external BLAS; I'm not sure how it got you LAPACK(generic) without BLAS(generic). -- Best regards, Ivan This email has been scanned for spam & viruses. If you believe this email should have been stopped by our filters, click the following link to report it (https://portal-uk.mailanyone.net/index.html#/outer/reportspam?token=dXNlcj1zaW1vbi5hbmRyZXdzQGJhYnJhaGFtLmFjLnVrO3RzPTE3MTUxODA5NjA7dXVpZD02NjNCOTVBMDY0RkEzNzNCMDM5QTkwQkZCQzJDRUJERjt0b2tlbj0yOTE5M2Q0NjFkZjQzYzhlMzk0ZDgxMTRkNjgyYTUwZjU3OWZlODgxOw%3D%3D). __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Compilation problems with R4.4.0
The lapack parts of the configure are: checking whether 'struct tm' includes tm_zone... yes checking whether 'struct tm' includes tm_gmtoff... yes checking for dgemm_ in -llapack... no checking for ATLAS routines in liblapack... no checking for dpstrf_ in -llapack... yes checking for liblapack dependency with both BLAS and LAPACK routines... no checking if LAPACK version >= 3.9.0... 3.9.0, so yes checking for iconv.h... yes checking for iconv... yes The lapack libraries are: $ rpm -qa | grep lapack lapack-3.9.0-10.el9.x86_64 lapack64_-3.9.0-10.el9.x86_64 lapack64-3.9.0-10.el9.x86_64 lapack-devel-3.9.0-10.el9.x86_64 -Original Message- From: Ivan Krylov Sent: 08 May 2024 16:09 To: Simon Andrews Cc: Simon Andrews via R-help ; Miguel Esteva Subject: Re: [R] Compilation problems with R4.4.0 В Wed, 8 May 2024 14:25:08 + Simon Andrews пишет: > #8 0x73f87c0b in dgesv ( > n=12884901891, nrhs=4294967299, > a=, > lda=12884901891, ipiv=..., b= optimized out>, ldb=12884901891, info=0 > ) at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgesv.f:167 > #9 0x750b2a17 in La_solve ( > tolin=, Bin=, A=0x18f2f68 > ) at Lapack.c:1246 > #10 mod_do_lapack ( > call=, op=, args=, > env= > ) at Lapack.c:1483 It looks like this R build is linked to a LAPACK. I now also notice LAPACK(generic) in the list of external libraries in your ./configure output. I've tried to link R to AlmaLinux's builds of reference BLAS and LAPACK using --with-blas='-l:libblas.so.3' --with-lapack='-l:liblapack.so.3' (where do I get libblas.so on AlmaLinux?), but that doesn't crash either. What does the config.log currently say about your BLAS and LAPACK situation? It's a number of lines between configure:47012: checking whether 'struct tm' includes tm_gmtoff and configure:48858: checking for iconv.h. If you'd like to link your R to custom BLAS and LAPACK, try specifying the necessary linker flags explicitly with --with-blas=-lwhatever, --with-lapack=-lwhatever. If you're fine with reference BLAS & LAPACK that come with R, try ./configure --without-blas --without-lapack. Normally, R's ./configure tries to prevent linking to an external LAPACK without linking to an external BLAS; I'm not sure how it got you LAPACK(generic) without BLAS(generic). -- Best regards, Ivan This email has been scanned for spam & viruses. If you believe this email should have been stopped by our filters, click the following link to report it (https://portal-uk.mailanyone.net/index.html#/outer/reportspam?token=dXNlcj1zaW1vbi5hbmRyZXdzQGJhYnJhaGFtLmFjLnVrO3RzPTE3MTUxODA5NjA7dXVpZD02NjNCOTVBMDY0RkEzNzNCMDM5QTkwQkZCQzJDRUJERjt0b2tlbj0yOTE5M2Q0NjFkZjQzYzhlMzk0ZDgxMTRkNjgyYTUwZjU3OWZlODgxOw%3D%3D). __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Compilation problems with R4.4.0
В Wed, 8 May 2024 14:25:08 + Simon Andrews пишет: > #8 0x73f87c0b in dgesv ( > n=12884901891, nrhs=4294967299, > a=, > lda=12884901891, ipiv=..., > b=, > ldb=12884901891, info=0 > ) at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgesv.f:167 > #9 0x750b2a17 in La_solve ( > tolin=, Bin=, A=0x18f2f68 > ) at Lapack.c:1246 > #10 mod_do_lapack ( > call=, op=, args=, > env= > ) at Lapack.c:1483 It looks like this R build is linked to a LAPACK. I now also notice LAPACK(generic) in the list of external libraries in your ./configure output. I've tried to link R to AlmaLinux's builds of reference BLAS and LAPACK using --with-blas='-l:libblas.so.3' --with-lapack='-l:liblapack.so.3' (where do I get libblas.so on AlmaLinux?), but that doesn't crash either. What does the config.log currently say about your BLAS and LAPACK situation? It's a number of lines between configure:47012: checking whether 'struct tm' includes tm_gmtoff and configure:48858: checking for iconv.h. If you'd like to link your R to custom BLAS and LAPACK, try specifying the necessary linker flags explicitly with --with-blas=-lwhatever, --with-lapack=-lwhatever. If you're fine with reference BLAS & LAPACK that come with R, try ./configure --without-blas --without-lapack. Normally, R's ./configure tries to prevent linking to an external LAPACK without linking to an external BLAS; I'm not sure how it got you LAPACK(generic) without BLAS(generic). -- Best regards, Ivan __ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
Re: [R] Compilation problems with R4.4.0
1
#62 0x77cb13ac in Rf_applyClosure (unpromise=TRUE,
suppliedvars=, rho=0x8eb288, arglist=,
op=0x7e0b70, call=0x78a960)
at eval.c:2333
#63 Rf_eval (e=0x78a960, rho=rho@entry=0x8eb288) at eval.c:1285
#64 0x77cb6322 in do_set (call=0x78a8b8, op=0x421338, args=0x78a8f0,
rho=0x8eb288) at ../../src/include/Rinlinedfuns.h:90
#65 0x77cb16b6 in Rf_eval (e=0x78a8b8, rho=rho@entry=0x8eb288) at
eval.c:1237
#66 0x77cb4e68 in do_begin (call=0x78a880, op=0x42c4a0, args=0x78a848,
rho=0x8eb288) at ../../src/include/Rinlinedfuns.h:90
#67 0x77cb16b6 in Rf_eval (e=e@entry=0x78a880, rho=rho@entry=0x8eb288)
at eval.c:1237
#68 0x77cb92ac in do_for (call=, op=,
args=, rho=) at eval.c:2892
#69 0x77cb16b6 in Rf_eval (e=0x78a068, rho=rho@entry=0x8eb288) at
eval.c:1237
#70 0x77cb4e68 in do_begin (call=0x78a030, op=0x42c4a0, args=0x789ff8,
rho=0x8eb288) at ../../src/include/Rinlinedfuns.h:90
#71 0x77cb16b6 in Rf_eval (e=e@entry=0x78a030, rho=rho@entry=0x8eb288)
at eval.c:1237
#72 0x77cb330f in R_execClosure (call=call@entry=0x8eb330,
newrho=newrho@entry=0x8eb288, sysparent=, rho=rho@entry=0x45a518,
arglist=arglist@entry=0x423210, op=op@entry=0x789e38) at eval.c:2398
#73 0x77cb40f7 in applyClosure_core (call=call@entry=0x8eb330,
op=op@entry=0x789e38, arglist=0x423210, rho=rho@entry=0x45a518,
--Type for more, q to quit, c to continue without paging--
suppliedvars=, unpromise=unpromise@entry=TRUE) at eval.c:2311
#74 0x77cb13ac in Rf_applyClosure (unpromise=TRUE,
suppliedvars=, rho=0x45a518, arglist=,
op=0x789e38, call=0x8eb330)
at eval.c:2333
#75 Rf_eval (e=0x8eb330, rho=0x45a518) at eval.c:1285
#76 0x77ce5a57 in setup_Rmainloop () at main.c:1166
#77 0x77ce6ae9 in Rf_mainloop () at main.c:1222
#78 0x0040106b in main (ac=, av=) at
Rmain.c:29
-Original Message-----
From: Ivan Krylov
Sent: 08 May 2024 15:12
To: Simon Andrews via R-help
Cc: Simon Andrews ; Miguel Esteva
Subject: Re: [R] Compilation problems with R4.4.0
Dear Simon,
В Wed, 8 May 2024 10:17:41 +
Simon Andrews via R-help пишет:
> I'm having a strange problem compiling R4.4.0 on an AlmaLinux9 box.
> make[4]: Entering directory '/bi/apps/R/R-4.4.0/src/library/grDevices'
> byte-compiling package 'grDevices'
>
> *** caught segfault ***
> address 0x18017a8110, cause 'memory not mapped'
>
> Traceback:
> 1: solve.default(rgb)
Miguel Esteva has recently complained about the same problem on RHEL9, but
didn't provide enough details, nor was I able to reproduce it
myself: https://stat.ethz.ch/pipermail/r-help/2024-May/479288.html
Thanks for letting us know it's reproducible on AlmaLinux and telling us your
compiler version!
Unfortunately, I wasn't able to reproduce the crash, neither with
gcc-toolset-13, nor with the ordinary gcc & gfortran 11.4.1 20231218 (Red Hat
11.4.1-3) from the repository. I see that your compiler version is slightly
different (11.4.1-2). I'm running `podman run -it --rm almalinux:9`. Would an
upgrade help?
Can you run R under the debugger and obtain a backtrace? Something like the
following, in the src/library/grDevices subdirectory:
_R_COMPILE_PKGS_=1 R_COMPILER_SUPPRESS_ALL=1 \ R_DEFAULT_PACKAGES=NULL
LC_ALL=C \ ../../../bin/R -d gdb --vanilla --no-echo -e \
'tools:::makeLazyLoading("grDevices")'
--
Best regards,
Ivan
This email has been scanned for spam & viruses. If you believe this email
should have been stopped by our filters, click the following link to report it
(https://portal-uk.mailanyone.net/index.html#/outer/reportspam?token=dXNlcj1zaW1vbi5hbmRyZXdzQGJhYnJhaGFtLmFjLnVrO3RzPTE3MTUxNzc1NTg7dXVpZD02NjNCODg1NTEyNjcyMzlDMjY5RkMwQTY5MUE2RDg5Njt0b2tlbj0zZjFiOWNmMGM5NTY3NjU3YjM0YmZhY2QwMTEzM2E3YmRlMDUxY2IwOw%3D%3D).
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
Re: [R] Compilation problems with R4.4.0
Dear Simon,
В Wed, 8 May 2024 10:17:41 +
Simon Andrews via R-help пишет:
> I'm having a strange problem compiling R4.4.0 on an AlmaLinux9 box.
> make[4]: Entering directory '/bi/apps/R/R-4.4.0/src/library/grDevices'
> byte-compiling package 'grDevices'
>
> *** caught segfault ***
> address 0x18017a8110, cause 'memory not mapped'
>
> Traceback:
> 1: solve.default(rgb)
Miguel Esteva has recently complained about the same problem on RHEL9,
but didn't provide enough details, nor was I able to reproduce it
myself: https://stat.ethz.ch/pipermail/r-help/2024-May/479288.html
Thanks for letting us know it's reproducible on AlmaLinux and telling
us your compiler version!
Unfortunately, I wasn't able to reproduce the crash, neither with
gcc-toolset-13, nor with the ordinary gcc & gfortran 11.4.1 20231218
(Red Hat 11.4.1-3) from the repository. I see that your compiler version
is slightly different (11.4.1-2). I'm running `podman run -it --rm
almalinux:9`. Would an upgrade help?
Can you run R under the debugger and obtain a backtrace? Something like
the following, in the src/library/grDevices subdirectory:
_R_COMPILE_PKGS_=1 R_COMPILER_SUPPRESS_ALL=1 \
R_DEFAULT_PACKAGES=NULL LC_ALL=C \
../../../bin/R -d gdb --vanilla --no-echo -e \
'tools:::makeLazyLoading("grDevices")'
--
Best regards,
Ivan
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
[R] Compilation problems with R4.4.0
I'm having a strange problem compiling R4.4.0 on an AlmaLinux9 box. I've
compiled previous versions OK on the same hardware/software (last was R4.3.2)
but 4.4.0 is repeatedly failing.
Configuration works OK.
./configure --prefix=/bi/apps/R/4.4.0 --enable-R-shlib
R is now configured for x86_64-pc-linux-gnu
Source directory:.
Installation directory: /bi/apps/R/4.4.0
C compiler: gcc -g -O2
Fortran fixed-form compiler: gfortran -g -O2
Default C++ compiler:g++ -std=gnu++17 -g -O2
C++11 compiler: g++ -std=gnu++11 -g -O2
C++14 compiler: g++ -std=gnu++14 -g -O2
C++17 compiler: g++ -std=gnu++17 -g -O2
C++20 compiler: g++ -std=gnu++20 -g -O2
C++23 compiler: g++ -std=gnu++23 -g -O2
Fortran free-form compiler: gfortran -g -O2
Obj-C compiler:
Interfaces supported:X11
External libraries: pcre2, readline, LAPACK(generic), curl
Additional capabilities: PNG, JPEG, TIFF, NLS, cairo, ICU
Options enabled: shared R library, shared BLAS, R profiling
Capabilities skipped:
Options not enabled: memory profiling
Recommended packages:yes
configure: WARNING: neither inconsolata.sty nor zi4.sty found: PDF vignettes
and package manuals will not be rendered optimally
configure: WARNING: I could not determine a browser
configure: WARNING: I could not determine a PDF viewer
..but after running make it gets though most of it then dies with:
make[4]: Entering directory '/bi/apps/R/R-4.4.0/src/library/grDevices'
byte-compiling package 'grDevices'
*** caught segfault ***
address 0x18017a8110, cause 'memory not mapped'
Traceback:
1: solve.default(rgb)
2: solve(rgb)
3: drop(whitexyz %*% solve(rgb))
4: make.rgb(red = c(0.625, 0.34), green = c(0.28, 0.595), blue = c(0.155,
0.07), gamma = 1.8, white = "D65", name = "Apple RGB")
5: eval(exprs[i], envir)
6: eval(exprs[i], envir)
7: sys.source(codeFile, env, keep.source = keep.source, keep.parse.data =
keep.parse.data)
8: doTryCatch(return(expr), name, parentenv, handler)
9: tryCatchOne(expr, names, parentenv, handlers[[1L]])
10: tryCatchList(expr, classes, parentenv, handlers)
11: tryCatch(expr, error = function(e) {call <- conditionCall(e)if
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch)))
call <- sys.call(-4L)dcall <- deparse(call, nlines = 1L)
prefix <- paste("Error in", dcall, ": ")LONG <- 75Lsm <-
strsplit(conditionMessage(e), "\n")[[1L]]w <- 14L + nchar(dcall, type =
"w") + nchar(sm[1L], type = "w")if (is.na(w)) w <- 14L +
nchar(dcall, type = "b") + nchar(sm[1L], type = "b")if
(w > LONG) prefix <- paste0(prefix, "\n ")}else prefix <-
"Error : "msg <- paste0(prefix, conditionMessage(e), "\n")
.Internal(seterrmessage(msg[1L]))if (!silent &&
isTRUE(getOption("show.error.messages"))) {cat(msg, file = outFile)
.Internal(printDeferredWarnings())}invisible(structure(msg, class =
"try-error", condition = e))})
12: try(sys.source(codeFile, env, keep.source = keep.source, keep.parse.data =
keep.parse.data))
13: loadNamespace(package = package, lib.loc = lib.loc, keep.source =
keep.source, keep.parse.data = keep.parse.data, partial = TRUE)
14: withCallingHandlers(expr, packageStartupMessage = function(c)
tryInvokeRestart("muffleMessage"))
15: suppressPackageStartupMessages(loadNamespace(package = package, lib.loc
= lib.loc, keep.source = keep.source, keep.parse.data = keep.parse.data,
partial = TRUE))
16: code2LazyLoadDB(package, lib.loc = lib.loc, keep.source = keep.source,
keep.parse.data = keep.parse.data, compress = compress, set.install.dir =
set.install.dir)
17: tools:::makeLazyLoading("grDevices")
An irrecoverable exception occurred. R is aborting now ...
make[4]: *** [../../../share/make/lazycomp.mk:9:
../../../library/grDevices/R/grDevices.rdb] Error 139
I can reproduce the error directly by running make in
/bi/apps/R/R-4.4.0/src/library/grDevices. Nothing strange is in my
environment, I'm using the stock version of make and gcc
$ which make
/usr/bin/make
$ which gcc
/usr/bin/gcc
$ make --version
GNU Make 4.3
Built for x86_64-redhat-linux-gnu
$ gcc --version
gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2)
I can't find any other instances of others hitting the same problem.
Any suggestions for what this could be?
Thanks
Simon.
[[alternative HTML version deleted]]
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
