June 02
On 6/1/21 2:18 PM, data pulverizer wrote:
> Doing `Runtime.initialize` is working with Julia but not yet R, I'm getting a clock/GLIBC error
> 
> ```
> 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
> ```
> 
> do I need to import anything else?

What's happening is that the dynamic linker is trying to resolve that symbol, but cannot find it in the given library.

Try `ldd code/rbasic.so` and see if it tells you the things it is looking for. Many times, you will see "Not found" or something and you know what library to install/look for.

Otherwise, it might be that librt.so.1 seemed to have __clock_nanosleep when it was built, but the librt.so.1 it is loading during runtime does not have it. Are you building on one machine and then running on another?

-Steve
June 02

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

>

What's happening is that the dynamic linker is trying to resolve that symbol, but cannot find it in the given library.

Try ldd code/rbasic.so and see if it tells you the things it is looking for. Many times, you will see "Not found" or something and you know what library to install/look for.

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)
>

Otherwise, it might be that librt.so.1 seemed to have __clock_nanosleep when it was built, but the librt.so.1 it is loading during runtime does not have it. Are you building on one machine and then running on another?

I am building and running on the same machine.

June 02

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

>

Doing Runtime.initialize is working with Julia but not yet R, I'm getting a clock/GLIBC error

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

do I need to import anything else?

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.

June 04

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

>

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.

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.

June 04

On Friday, 4 June 2021 at 07:26:53 UTC, data pulverizer 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.

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).

June 04

Dub is probably not much of a help :)

June 04

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

>

Dub is probably not much of a help :)

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.

June 05

On Friday, 4 June 2021 at 15:19:17 UTC, bachmeier 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).

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.

Next ›   Last »
1 2