On Wednesday, 2 June 2021 at 17:49:49 UTC, Steven Schveighoffer wrote:

I ran ldd, it looks as if all the symbols are resolved

$ ldd rbasic.so
	linux-vdso.so.1 (0x00007ffe7af56000)
	libR.so => /lib/libR.so (0x00007f269adb8000)
	libdruntime-ldc-shared.so.94 => /snap/ldc2/170/bin/../lib/libdruntime-ldc-shared.so.94 (0x00007f269ac0c000)
	libblas.so.3 => /lib/x86_64-linux-gnu/libblas.so.3 (0x00007f269920d000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f26990be000)
	libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8 (0x00007f269906e000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f2698fdc000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f2698fb3000)
	libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f2698fa0000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2698f84000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2698f7e000)
	libicuuc.so.66 => /lib/x86_64-linux-gnu/libicuuc.so.66 (0x00007f2698d98000)
	libicui18n.so.66 => /lib/x86_64-linux-gnu/libicui18n.so.66 (0x00007f2698a97000)
	libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f2698a55000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2698a32000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2698840000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f269b29e000)
	librt.so.1 => /snap/core/current/lib/x86_64-linux-gnu/librt.so.1 (0x00007f2698638000)
	libgcc_s.so.1 => /snap/core/current/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2698420000)
	libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f26983f0000)
	libicudata.so.66 => /lib/x86_64-linux-gnu/libicudata.so.66 (0x00007f269692f000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f269674e000)

I am building and running on the same machine.

On Tuesday, 1 June 2021 at 18:18:35 UTC, data pulverizer wrote:

Error in dyn.load("rbasic.so") :
  unable to load shared object 'code/rbasic.so':
  lib/x86_64-linux-gnu/librt.so.1: undefined symbol: __clock_nanosleep, version GLIBC_PRIVATE

Are you aware of my embedr project, which handles all that for you, and does a lot of other stuff?

https://embedr.netlify.app

If you want to do it yourself, you can see the boilerplate you need to add to call a shared library from R here: https://bitbucket.org/bachmeil/embedr/src/bebf67e5b30cd4163214c7f44f9907e7d7490dc0/R/compile.R#lines-99

If you want to read the R manual, the relevant section is here:
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#dyn_002eload-and-dyn_002eunload
If you don't do that, it's unlikely to work unless you get lucky. If you want to load foo.so, you need a corresponding R_init_foo function where you call Runtime.initialize.

On Wednesday, 2 June 2021 at 23:23:58 UTC, bachmeier wrote:

Thanks. Looks like I have some more reading to do. I did know about embedr, but I saw it had dependencies and I wanted a standalone and fully transparent D solution. I'm already calling R routines from D using standalone Rmath and being able to call D from R and D have independent full access to R's internals would be awesome. But your package certainly provides very useful information.

The reference to R's dyn.load internals looks useful and relevant and I'll be trying those once I get the time. Probably during the weekend.

On Friday, 4 June 2021 at 07:26:53 UTC, data pulverizer wrote:

It requires an R package if you want to call D functions from R. You need to link to R itself if you want to do something like pass a vector from R to D and then access that data from D. Since R is aware of the location of all the underlying libraries, it's easiest to let it generate the dub.sdl for you.

I guess you're using the older .C interface as done here. Good enough if passing double* and int* pointers to D functions will suffice. Only thing you need to do to initialize the D runtime is add this to your D code

struct DllInfo;

extern(C) void R_init_libfoo(DllInfo * info) {
    Runtime.initialize();
}

where foo is the name of the library you're loading (foo.so).

Dub is probably not much of a help :)

On Friday, 4 June 2021 at 15:33:32 UTC, Alain De Vos wrote:

That's right. I typically don't use Dub when I'm calling D functions from R. It's the only way you can use a Dub package like Mir, though, so that's why you might want it to generate a dub.sdl for you.

On Friday, 4 June 2021 at 15:19:17 UTC, bachmeier wrote:

struct DllInfo;

extern(C) void R_init_libfoo(DllInfo * info) {
    Runtime.initialize();
}

I've just read the documentation and had a go, compiling with GDC worked for both .C and .Call.

I tried with all three compilers DMD, LDC, and GDC, and looked at the outputs with the nm tool. I don't think this matters much but DMD and LDC are more likely to list functions (DMD) or symbols in referenced modules (LDC) as weak symbols. I think the more likely the reason GDC worked is because it is a GNU compiler this has full GLIBC compatibility with reference to the librt.so.1 GLIBC_PRIVATE error.

The R ext documentation you kindly referenced says:

"By default, R uses the operating-system-specific dynamic loader to lookup the symbol in all loaded DLLs and the R executable or libraries it is linked to."

and that:

"Registering routines has two main advantages: it provides a faster way to find the address of the entry point via tables stored in the DLL at compilation time, and it provides a run-time check that the entry point is called with the right number of arguments and, optionally, the right argument types."

So registering symbols is not the issue. The error was specific to GLIBC which is probably why the GNU compiler worked.

Thank you.