Skip to content

R build BLAS/LAPACK debugging ('dgemmtr_' undefined)

8 messages · Avraham Adler, Dirk Eddelbuettel, Ben Bolker +1 more

#
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
#
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:
#
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
#
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 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.
#
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
#
? Mon, 26 Jan 2026 12:45:41 -0500
Ben Bolker <bbolker at gmail.com> ?????:
.../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.
#
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: