I'm sure I'm doing something dumb, but having trouble building R from source on PopOS! 22.04 LTS (debian/Ubuntu 'jammy' derivative): "undefined symbol: dgemmtr_" when trying to load stuff from LAPACK. R appears to find stuff at the configure step (FWIW I get the same error below if I take out "with-blas=-lopenblas") $ ../r-devel/configure --enable-R-shlib --enable-memory-profiling --with-blas=-lopenblas | grep blas configure: WARNING: C23 support is unavailable checking for dgemm_ in -lopenblas... yes config.status: creating src/extra/blas/Makefile Then `make` fails with: byte-compiling package 'grDevices' Warning in solve.default(rgb) : unable to load shared object '/home/bolker/R/r-build/modules//lapack.so': /home/bolker/R/r-build/lib/libRlapack.so: undefined symbol: dgemmtr_ Error in solve.default(rgb) : LAPACK routines cannot be loaded I do see a NEWS item from R 4.5.0 https://github.com/r-devel/r-svn/blob/42e81d981a540f4afc01d1002a64ab347eb5dc15/doc/NEWS.Rd#L956-L961 (I thought things were working until recently, but I haven't re-built from scratch in a while ...) \item This update was mainly bug fixes but contained a barely documented major change. The set of BLAS routines had been unchanged since 1988, so throughout \R's history. This update introduced new BLAS routines \code{dgemmtr} and \code{zgemmtr} which are now used by LAPACK routines. This means that BLAS implementations are no longer interchangeable. Section A.3.1 https://rstudio.github.io/r-manuals/r-admin/Essential-and-useful-other-programs-under-a-Unix-alike.html: > The configure code checks that the external BLAS is complete (as of LAPACK 3.9.1: it must include all double precision and double complex routines, as well as LSAME), and appears to be usable. However, an external BLAS has to be usable from a shared object (so must contain position-independent code), and that is not checked. I'd be surprised if by BLAS libraries *didn't* contain PIC, but ... ?? Suggestions for diagnostics/debugging welcome ... cheers Ben Bolker
R build BLAS/LAPACK debugging ('dgemmtr_' undefined)
8 messages · Avraham Adler, Dirk Eddelbuettel, Ben Bolker +1 more
Possibly related, ever since that change to R, I found I have to build OpenBLAS *with* Lapack because of the change in where OpenBLAS "stores" some functions. See issue 4684 in the OpenBLAS Github repo [1]. As a result, you will see a much larger .a file. However, the processor-named and unnamed (just libopenblas.a) should now be the same after 4692 [2]. Either one works, at least for me, Hope that helps, Avi [1] https://github.com/OpenMathLib/OpenBLAS/issues/4684 [2] https://github.com/OpenMathLib/OpenBLAS/discussions/4692
On Mon, Jan 26, 2026 at 12:45?PM Ben Bolker <bbolker at gmail.com> wrote:
I'm sure I'm doing something dumb, but having trouble building R from source on PopOS! 22.04 LTS (debian/Ubuntu 'jammy' derivative): "undefined symbol: dgemmtr_" when trying to load stuff from LAPACK. R appears to find stuff at the configure step (FWIW I get the same error below if I take out "with-blas=-lopenblas") $ ../r-devel/configure --enable-R-shlib --enable-memory-profiling --with-blas=-lopenblas | grep blas configure: WARNING: C23 support is unavailable checking for dgemm_ in -lopenblas... yes config.status: creating src/extra/blas/Makefile Then `make` fails with: byte-compiling package 'grDevices' Warning in solve.default(rgb) : unable to load shared object '/home/bolker/R/r-build/modules//lapack.so': /home/bolker/R/r-build/lib/libRlapack.so: undefined symbol: dgemmtr_ Error in solve.default(rgb) : LAPACK routines cannot be loaded I do see a NEWS item from R 4.5.0 https://github.com/r-devel/r-svn/blob/42e81d981a540f4afc01d1002a64ab347eb5dc15/doc/NEWS.Rd#L956-L961 (I thought things were working until recently, but I haven't re-built from scratch in a while ...) \item This update was mainly bug fixes but contained a barely documented major change. The set of BLAS routines had been unchanged since 1988, so throughout \R's history. This update introduced new BLAS routines \code{dgemmtr} and \code{zgemmtr} which are now used by LAPACK routines. This means that BLAS implementations are no longer interchangeable. Section A.3.1 https://rstudio.github.io/r-manuals/r-admin/Essential-and-useful-other-programs-under-a-Unix-alike.html:
> The configure code checks that the external BLAS is complete (as of
LAPACK 3.9.1: it must include all double precision and double complex
routines, as well as LSAME), and appears to be usable. However, an
external BLAS has to be usable from a shared object (so must contain
position-independent code), and that is not checked.
I'd be surprised if by BLAS libraries *didn't* contain PIC, but ... ??
Suggestions for diagnostics/debugging welcome ...
cheers
Ben Bolker
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On 26 January 2026 at 12:45, Ben Bolker wrote:
| | I'm sure I'm doing something dumb, but having trouble building R from | source on PopOS! 22.04 LTS (debian/Ubuntu 'jammy' derivative): | "undefined symbol: dgemmtr_" when trying to load stuff from LAPACK. | | R appears to find stuff at the configure step (FWIW I get the same error | below if I take out "with-blas=-lopenblas") | | $ ../r-devel/configure --enable-R-shlib --enable-memory-profiling | --with-blas=-lopenblas | grep blas | configure: WARNING: C23 support is unavailable | checking for dgemm_ in -lopenblas... yes | config.status: creating src/extra/blas/Makefile FWIW in all my build script(s) (for local r-devel builds, or the Debian R package, or container builds from source) I explicitly set the --with-blas and the --with-lapack flags. As dgemm() is (well known) LAPACK routine [1] I think you are "simply" forgetting to link with LAPACK here. Cheers, Dirk [1] https://www.netlib.org/lapack/explore-html/dd/d09/group__gemm_ga1e899f8453bcbfde78e91a86a2dab984.html | | Then `make` fails with: | | byte-compiling package 'grDevices' | Warning in solve.default(rgb) : | unable to load shared object '/home/bolker/R/r-build/modules//lapack.so': | /home/bolker/R/r-build/lib/libRlapack.so: undefined symbol: dgemmtr_ | Error in solve.default(rgb) : LAPACK routines cannot be loaded | | I do see a NEWS item from R 4.5.0 | https://github.com/r-devel/r-svn/blob/42e81d981a540f4afc01d1002a64ab347eb5dc15/doc/NEWS.Rd#L956-L961 | (I thought things were working until recently, but I haven't re-built | from scratch in a while ...) | | \item This update was mainly bug fixes but contained a barely | documented major change. The set of BLAS routines had been | unchanged since 1988, so throughout \R's history. This update | introduced new BLAS routines \code{dgemmtr} and \code{zgemmtr} | which are now used by LAPACK routines. This means that BLAS | implementations are no longer interchangeable. | | Section A.3.1 | https://rstudio.github.io/r-manuals/r-admin/Essential-and-useful-other-programs-under-a-Unix-alike.html: | | > The configure code checks that the external BLAS is complete (as of | LAPACK 3.9.1: it must include all double precision and double complex | routines, as well as LSAME), and appears to be usable. However, an | external BLAS has to be usable from a shared object (so must contain | position-independent code), and that is not checked. | | I'd be surprised if by BLAS libraries *didn't* contain PIC, but ... ?? | | Suggestions for diagnostics/debugging welcome ... | | cheers | Ben Bolker | | ______________________________________________ | R-devel at r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
Hmm, good idea but that isn't seeming to help me?
../r-devel/configure --enable-R-shlib --enable-memory-profiling
--with-blas=-lopenblas --with-lapack=-llapack | egrep "(lapack|blas)"
configure: WARNING: C23 support is unavailable
checking for dgemm_ in -lopenblas... yes
checking for dpstrf_ in -llapack... yes
config.status: creating src/extra/blas/Makefile
config.status: creating src/modules/lapack/Makefile
Then `make` gives me the same error. (I guess I could look at the
rocker Dockerfiles and try to copy them exactly?)
cheers
Ben
On 2026-01-26 1:22 p.m., Dirk Eddelbuettel wrote:
On 26 January 2026 at 12:45, Ben Bolker wrote: | | I'm sure I'm doing something dumb, but having trouble building R from | source on PopOS! 22.04 LTS (debian/Ubuntu 'jammy' derivative): | "undefined symbol: dgemmtr_" when trying to load stuff from LAPACK. | | R appears to find stuff at the configure step (FWIW I get the same error | below if I take out "with-blas=-lopenblas") | | $ ../r-devel/configure --enable-R-shlib --enable-memory-profiling | --with-blas=-lopenblas | grep blas | configure: WARNING: C23 support is unavailable | checking for dgemm_ in -lopenblas... yes | config.status: creating src/extra/blas/Makefile FWIW in all my build script(s) (for local r-devel builds, or the Debian R package, or container builds from source) I explicitly set the --with-blas and the --with-lapack flags. As dgemm() is (well known) LAPACK routine [1] I think you are "simply" forgetting to link with LAPACK here. Cheers, Dirk [1] https://www.netlib.org/lapack/explore-html/dd/d09/group__gemm_ga1e899f8453bcbfde78e91a86a2dab984.html | | Then `make` fails with: | | byte-compiling package 'grDevices' | Warning in solve.default(rgb) : | unable to load shared object '/home/bolker/R/r-build/modules//lapack.so': | /home/bolker/R/r-build/lib/libRlapack.so: undefined symbol: dgemmtr_ | Error in solve.default(rgb) : LAPACK routines cannot be loaded | | I do see a NEWS item from R 4.5.0 | https://github.com/r-devel/r-svn/blob/42e81d981a540f4afc01d1002a64ab347eb5dc15/doc/NEWS.Rd#L956-L961 | (I thought things were working until recently, but I haven't re-built | from scratch in a while ...) | | \item This update was mainly bug fixes but contained a barely | documented major change. The set of BLAS routines had been | unchanged since 1988, so throughout \R's history. This update | introduced new BLAS routines \code{dgemmtr} and \code{zgemmtr} | which are now used by LAPACK routines. This means that BLAS | implementations are no longer interchangeable. | | Section A.3.1 | https://rstudio.github.io/r-manuals/r-admin/Essential-and-useful-other-programs-under-a-Unix-alike.html: | | > The configure code checks that the external BLAS is complete (as of | LAPACK 3.9.1: it must include all double precision and double complex | routines, as well as LSAME), and appears to be usable. However, an | external BLAS has to be usable from a shared object (so must contain | position-independent code), and that is not checked. | | I'd be surprised if by BLAS libraries *didn't* contain PIC, but ... ?? | | Suggestions for diagnostics/debugging welcome ... | | cheers | Ben Bolker | | ______________________________________________ | R-devel at r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel
Dr. Benjamin Bolker Professor, Mathematics & Statistics and Biology, McMaster University Associate Chair (Graduate), Department of Mathematics & Statistics Director, School of Computational Science and Engineering > E-mail is sent at my convenience; I don't expect replies outside of working hours.
On 26 January 2026 at 13:29, Ben Bolker wrote:
| Hmm, good idea but that isn't seeming to help me? | | ../r-devel/configure --enable-R-shlib --enable-memory-profiling | --with-blas=-lopenblas --with-lapack=-llapack | egrep "(lapack|blas)" | | configure: WARNING: C23 support is unavailable | checking for dgemm_ in -lopenblas... yes | checking for dpstrf_ in -llapack... yes | config.status: creating src/extra/blas/Makefile | config.status: creating src/modules/lapack/Makefile | | Then `make` gives me the same error. (I guess I could look at the | rocker Dockerfiles and try to copy them exactly?) Couple of things to try: 1) I would make sure you do have the corresponding -dev packages for building, not just the runtime packages. I cannot look onto your machines. 2) I would simplify; my builds actually just say --with-blas --with-lapack as the Debian (and Ubuntu and PopOS!) package management sets the right default, usually. So if you want openblas, install the corresponding packages (and these days there are several). 3) If you are really lost or mad, follow reproducible steps. My Debian package setup is public, my Dockerfiles are public, I am sure the R Installation and Admin manual has things to say. Lastly, we probably should have this chat on r-sig-debian to not bore our good friends using windows, macos, fedora, ... Dirk | | cheers | Ben | | |
| On 2026-01-26 1:22 p.m., Dirk Eddelbuettel wrote:
| >
| > On 26 January 2026 at 12:45, Ben Bolker wrote:
| > | | > | I'm sure I'm doing something dumb, but having trouble building R from | > | source on PopOS! 22.04 LTS (debian/Ubuntu 'jammy' derivative): | > | "undefined symbol: dgemmtr_" when trying to load stuff from LAPACK. | > | | > | R appears to find stuff at the configure step (FWIW I get the same error | > | below if I take out "with-blas=-lopenblas") | > | | > | $ ../r-devel/configure --enable-R-shlib --enable-memory-profiling | > | --with-blas=-lopenblas | grep blas | > | configure: WARNING: C23 support is unavailable | > | checking for dgemm_ in -lopenblas... yes | > | config.status: creating src/extra/blas/Makefile | > | > FWIW in all my build script(s) (for local r-devel builds, or the Debian R | > package, or container builds from source) I explicitly set the --with-blas | > and the --with-lapack flags. As dgemm() is (well known) LAPACK routine [1] I | > think you are "simply" forgetting to link with LAPACK here. | > | > Cheers, Dirk | > | > [1] https://www.netlib.org/lapack/explore-html/dd/d09/group__gemm_ga1e899f8453bcbfde78e91a86a2dab984.html | > | > | | > | Then `make` fails with: | > | | > | byte-compiling package 'grDevices' | > | Warning in solve.default(rgb) : | > | unable to load shared object '/home/bolker/R/r-build/modules//lapack.so': | > | /home/bolker/R/r-build/lib/libRlapack.so: undefined symbol: dgemmtr_ | > | Error in solve.default(rgb) : LAPACK routines cannot be loaded | > | | > | I do see a NEWS item from R 4.5.0 | > | https://github.com/r-devel/r-svn/blob/42e81d981a540f4afc01d1002a64ab347eb5dc15/doc/NEWS.Rd#L956-L961 | > | (I thought things were working until recently, but I haven't re-built | > | from scratch in a while ...) | > | | > | \item This update was mainly bug fixes but contained a barely | > | documented major change. The set of BLAS routines had been | > | unchanged since 1988, so throughout \R's history. This update | > | introduced new BLAS routines \code{dgemmtr} and \code{zgemmtr} | > | which are now used by LAPACK routines. This means that BLAS | > | implementations are no longer interchangeable. | > | | > | Section A.3.1 | > | https://rstudio.github.io/r-manuals/r-admin/Essential-and-useful-other-programs-under-a-Unix-alike.html: | > | | > | > The configure code checks that the external BLAS is complete (as of | > | LAPACK 3.9.1: it must include all double precision and double complex | > | routines, as well as LSAME), and appears to be usable. However, an | > | external BLAS has to be usable from a shared object (so must contain | > | position-independent code), and that is not checked. | > | | > | I'd be surprised if by BLAS libraries *didn't* contain PIC, but ... ?? | > | | > | Suggestions for diagnostics/debugging welcome ... | > | | > | cheers | > | Ben Bolker | > | | > | ______________________________________________ | > | R-devel at r-project.org mailing list | > | https://stat.ethz.ch/mailman/listinfo/r-devel | > | | -- | Dr. Benjamin Bolker | Professor, Mathematics & Statistics and Biology, McMaster University | Associate Chair (Graduate), Department of Mathematics & Statistics | Director, School of Computational Science and Engineering | > E-mail is sent at my convenience; I don't expect replies outside of working hours.
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
On 26 January 2026 at 12:52, Dirk Eddelbuettel wrote:
|
| On 26 January 2026 at 13:29, Ben Bolker wrote:
| | Hmm, good idea but that isn't seeming to help me? | | | | ../r-devel/configure --enable-R-shlib --enable-memory-profiling | | --with-blas=-lopenblas --with-lapack=-llapack | egrep "(lapack|blas)" | | | | configure: WARNING: C23 support is unavailable | | checking for dgemm_ in -lopenblas... yes | | checking for dpstrf_ in -llapack... yes | | config.status: creating src/extra/blas/Makefile | | config.status: creating src/modules/lapack/Makefile | | | | Then `make` gives me the same error. (I guess I could look at the | | rocker Dockerfiles and try to copy them exactly?) | | Couple of things to try: | | 1) I would make sure you do have the corresponding -dev packages for | building, not just the runtime packages. I cannot look onto your machines. | | 2) I would simplify; my builds actually just say --with-blas --with-lapack as | the Debian (and Ubuntu and PopOS!) package management sets the right default, | usually. So if you want openblas, install the corresponding packages (and | these days there are several). | | 3) If you are really lost or mad, follow reproducible steps. My Debian | package setup is public, my Dockerfiles are public, I am sure the R | Installation and Admin manual has things to say. 4) Kurt's configure script is also very good. You can just run re-run `./configure` and it should give you helpful output. Dirk | Lastly, we probably should have this chat on r-sig-debian to not bore our | good friends using windows, macos, fedora, ... | | Dirk | | | | | cheers | | Ben | | | | | |
| | On 2026-01-26 1:22 p.m., Dirk Eddelbuettel wrote:
| | >
| | > On 26 January 2026 at 12:45, Ben Bolker wrote:
| | > | | | > | I'm sure I'm doing something dumb, but having trouble building R from | | > | source on PopOS! 22.04 LTS (debian/Ubuntu 'jammy' derivative): | | > | "undefined symbol: dgemmtr_" when trying to load stuff from LAPACK. | | > | | | > | R appears to find stuff at the configure step (FWIW I get the same error | | > | below if I take out "with-blas=-lopenblas") | | > | | | > | $ ../r-devel/configure --enable-R-shlib --enable-memory-profiling | | > | --with-blas=-lopenblas | grep blas | | > | configure: WARNING: C23 support is unavailable | | > | checking for dgemm_ in -lopenblas... yes | | > | config.status: creating src/extra/blas/Makefile | | > | | > FWIW in all my build script(s) (for local r-devel builds, or the Debian R | | > package, or container builds from source) I explicitly set the --with-blas | | > and the --with-lapack flags. As dgemm() is (well known) LAPACK routine [1] I | | > think you are "simply" forgetting to link with LAPACK here. | | > | | > Cheers, Dirk | | > | | > [1] https://www.netlib.org/lapack/explore-html/dd/d09/group__gemm_ga1e899f8453bcbfde78e91a86a2dab984.html | | > | | > | | | > | Then `make` fails with: | | > | | | > | byte-compiling package 'grDevices' | | > | Warning in solve.default(rgb) : | | > | unable to load shared object '/home/bolker/R/r-build/modules//lapack.so': | | > | /home/bolker/R/r-build/lib/libRlapack.so: undefined symbol: dgemmtr_ | | > | Error in solve.default(rgb) : LAPACK routines cannot be loaded | | > | | | > | I do see a NEWS item from R 4.5.0 | | > | https://github.com/r-devel/r-svn/blob/42e81d981a540f4afc01d1002a64ab347eb5dc15/doc/NEWS.Rd#L956-L961 | | > | (I thought things were working until recently, but I haven't re-built | | > | from scratch in a while ...) | | > | | | > | \item This update was mainly bug fixes but contained a barely | | > | documented major change. The set of BLAS routines had been | | > | unchanged since 1988, so throughout \R's history. This update | | > | introduced new BLAS routines \code{dgemmtr} and \code{zgemmtr} | | > | which are now used by LAPACK routines. This means that BLAS | | > | implementations are no longer interchangeable. | | > | | | > | Section A.3.1 | | > | https://rstudio.github.io/r-manuals/r-admin/Essential-and-useful-other-programs-under-a-Unix-alike.html: | | > | | | > | > The configure code checks that the external BLAS is complete (as of | | > | LAPACK 3.9.1: it must include all double precision and double complex | | > | routines, as well as LSAME), and appears to be usable. However, an | | > | external BLAS has to be usable from a shared object (so must contain | | > | position-independent code), and that is not checked. | | > | | | > | I'd be surprised if by BLAS libraries *didn't* contain PIC, but ... ?? | | > | | | > | Suggestions for diagnostics/debugging welcome ... | | > | | | > | cheers | | > | Ben Bolker | | > | | | > | ______________________________________________ | | > | R-devel at r-project.org mailing list | | > | https://stat.ethz.ch/mailman/listinfo/r-devel | | > | | | | -- | | Dr. Benjamin Bolker | | Professor, Mathematics & Statistics and Biology, McMaster University | | Associate Chair (Graduate), Department of Mathematics & Statistics | | Director, School of Computational Science and Engineering | | > E-mail is sent at my convenience; I don't expect replies outside of working hours. | | -- | dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
? Mon, 26 Jan 2026 12:45:41 -0500 Ben Bolker <bbolker at gmail.com> ?????:
Then `make` fails with: byte-compiling package 'grDevices' Warning in solve.default(rgb) : unable to load shared object '/home/bolker/R/r-build/modules//lapack.so': /home/bolker/R/r-build/lib/libRlapack.so: undefined symbol: dgemmtr_ Error in solve.default(rgb) : LAPACK routines cannot be loaded
.../configure --with-2025blas should help with this by linking the subroutines missing in older versions of OpenBLAS but required by R-bundled LAPACK from a separate file.
Best regards, Ivan
Thanks everyone, this is working now (I did a few too many things at
once to be sure: (1) installed lopenblas-devel; (2) used
--with-2025blas; (3) tried `make` without running in parallel, i.e. not
`make -j 10` ...)
cheers
Ben Bolker
On 2026-01-26 2:28 p.m., Ivan Krylov wrote:
? Mon, 26 Jan 2026 12:45:41 -0500 Ben Bolker <bbolker at gmail.com> ?????:
Then `make` fails with:
byte-compiling package 'grDevices'
Warning in solve.default(rgb) :
unable to load shared object
'/home/bolker/R/r-build/modules//lapack.so':
/home/bolker/R/r-build/lib/libRlapack.so: undefined symbol: dgemmtr_
Error in solve.default(rgb) : LAPACK routines cannot be loaded
.../configure --with-2025blas should help with this by linking the subroutines missing in older versions of OpenBLAS but required by R-bundled LAPACK from a separate file.