Re: [R-pkg-devel] Compile issues on r-devel-linux-x86_64-debian-clang with OpenMP
On 23 May 2024 at 20:02, Ivan Krylov wrote:
| On Wed, 22 May 2024 09:18:13 -0500
| Dirk Eddelbuettel wrote:
|
| > Testing via 'nm' as you show is possible but not exactly 'portable'.
| > So any suggestions as to what to condition on here?
|
| (My apologies if you already got an answer from Kurt. I think we're not
| seeing his mails to the list.)
|
| Perhaps take the configure test a bit further and try to dyn.load() the
| resulting shared object? To be extra sure, call the function that uses
| the OpenMP features? (Some weird systems may have lazy binding enabled,
| making dyn.load() succeed but crashing the process on invocation of a
| missing function.)
|
| On GNU/Linux, the linker will happily leave undefined symbols in when
| creating a shared library (unlike on, say, Windows, where extern void
| foo(void); foo(); is a link-time error unless an object file or an
| import library providing foo() is also present). When loading such a
| library, the operation fails unless the missing symbols are already
| present in the address space of the process (e.g. from a different
| shared library).
|
| A fresh process of R built without OpenMP support will neither link in
| the OpenMP runtime while running SHLIB nor have the OpenMP runtime
| loaded and so should successfully fail the test.
|
| I also wouldn't call the entry point "main" just in case some future
| compiler considers this a violation of the rules™ [*] and breaks the
| code. extern "C" void configtest(int*) would be compatible with .C()
| without having to talk to R's memory manager:
|
| # The configure script:
| cat > test-omp.cpp <
| extern "C" void configtest(int * arg) {
| *arg = omp_get_num_threads();
| }
| EOF
| # Without the following you're relying on the GNU/Linux-like behaviour
| # w.r.t. undefined symbols (see WRE 1.2.1.1):
| cat > Makevars
Re: [R-pkg-devel] Compile issues on r-devel-linux-x86_64-debian-clang with OpenMP
On Wed, 22 May 2024 09:18:13 -0500
Dirk Eddelbuettel wrote:
> Testing via 'nm' as you show is possible but not exactly 'portable'.
> So any suggestions as to what to condition on here?
(My apologies if you already got an answer from Kurt. I think we're not
seeing his mails to the list.)
Perhaps take the configure test a bit further and try to dyn.load() the
resulting shared object? To be extra sure, call the function that uses
the OpenMP features? (Some weird systems may have lazy binding enabled,
making dyn.load() succeed but crashing the process on invocation of a
missing function.)
On GNU/Linux, the linker will happily leave undefined symbols in when
creating a shared library (unlike on, say, Windows, where extern void
foo(void); foo(); is a link-time error unless an object file or an
import library providing foo() is also present). When loading such a
library, the operation fails unless the missing symbols are already
present in the address space of the process (e.g. from a different
shared library).
A fresh process of R built without OpenMP support will neither link in
the OpenMP runtime while running SHLIB nor have the OpenMP runtime
loaded and so should successfully fail the test.
I also wouldn't call the entry point "main" just in case some future
compiler considers this a violation of the rules™ [*] and breaks the
code. extern "C" void configtest(int*) would be compatible with .C()
without having to talk to R's memory manager:
# The configure script:
cat > test-omp.cpp <
extern "C" void configtest(int * arg) {
*arg = omp_get_num_threads();
}
EOF
# Without the following you're relying on the GNU/Linux-like behaviour
# w.r.t. undefined symbols (see WRE 1.2.1.1):
cat > Makevars
Re: [R-pkg-devel] Compile issues on r-devel-linux-x86_64-debian-clang with OpenMP
On 2024-05-23 11:49 a.m., Dirk Eddelbuettel wrote: On 22 May 2024 at 14:03, Duncan Murdoch wrote: | On 2024-05-22 10:18 a.m., Dirk Eddelbuettel wrote: | > | > On 22 May 2024 at 13:54, Nixon, Michelle Pistner wrote: | > | Thank you both for your responses and help! Kurt-- your message makes a lot of | > | sense. I'll try to debug soon and will reach out if I have more questions. | > | > Interesting. | > | > Kurt, is there a recommended way to test for this (rare, I may add) case of | > 'OpenMP present but usage verboten by R' ? I do not see an option for 'R CMD | > config' jumping out, and there is no pkg-config file either. | > | > Testing via 'nm' as you show is possible but not exactly 'portable'. So any | > suggestions as to what to condition on here? Michelle did AFAICT the Right | > Thing (TM) by 'borrowing' from the fairly mature check in RcppArmadillo. | | Not that I know much about writing configure tests, but won't | src/include/config.h in the R build dir have "HAVE_OPENMP" defined if ^^ | OpenMP is supported? I think what Michelle and I are after is for an _installed_ version of R to tell us if we can, or cannot, use OpenMP. Maybe capabilities() needs and extension? Right, sorry. I thought that file was distributed, but it's Rconfig.h that gets installed, and it only has a subset of the definitions. Duncan __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Compile issues on r-devel-linux-x86_64-debian-clang with OpenMP
On 22 May 2024 at 14:03, Duncan Murdoch wrote: | On 2024-05-22 10:18 a.m., Dirk Eddelbuettel wrote: | > | > On 22 May 2024 at 13:54, Nixon, Michelle Pistner wrote: | > | Thank you both for your responses and help! Kurt-- your message makes a lot of | > | sense. I'll try to debug soon and will reach out if I have more questions. | > | > Interesting. | > | > Kurt, is there a recommended way to test for this (rare, I may add) case of | > 'OpenMP present but usage verboten by R' ? I do not see an option for 'R CMD | > config' jumping out, and there is no pkg-config file either. | > | > Testing via 'nm' as you show is possible but not exactly 'portable'. So any | > suggestions as to what to condition on here? Michelle did AFAICT the Right | > Thing (TM) by 'borrowing' from the fairly mature check in RcppArmadillo. | | Not that I know much about writing configure tests, but won't | src/include/config.h in the R build dir have "HAVE_OPENMP" defined if ^^ | OpenMP is supported? I think what Michelle and I are after is for an _installed_ version of R to tell us if we can, or cannot, use OpenMP. Maybe capabilities() needs and extension? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
