[R] dyn.load(now = FALSE) not actually lazy?

Ivan Krylov kry|ov@r00t @end|ng |rom gm@||@com
Thu Feb 2 10:10:25 CET 2023

В Thu, 2 Feb 2023 13:35:39 +1100
Michael Milton <ttmigueltt using gmail.com> пишет:

> The gist of it is that, indeed, R starts to look for dependent
> libraries even if now=FALSE.

I don't think that R does that. Here's a program that should do the
same thing that R does when you call dyn.load(now = FALSE):

#include <dlfcn.h>
#include <stdio.h>

int main(int argc, char ** argv) {
	if (argc != 2) {
		printf("Usage: %s path/to/library.so\n", argv[0]);
		return -1;

	void * ptr = dlopen(argv[1], RTLD_LAZY);
	if (!ptr) {
		printf("%s\n", dlerror());
		return 1;

	return 0;

Link it with -ldl. If you launch it with LD_DEBUG=all (see also: the
output when you launch something with LD_DEBUG=help), it should give you
even more information about the shared object loading process.

> /stornext/System/data/tools/pgsql/pgsql-15.1/lib/libpqwalreceiver.so:
> error: symbol lookup error: undefined symbol: work_mem (fatal)

I think I have an explanation for this. work_mem turns out to be a
global variable, not a function:


Indeed, libpqwalreceiver includes the header where the variable is
declared and accesses it:


I guess that there's no way for the dynamic loader to postpone the
resolution of an import that's a variable, because it has to be a
pointer where the code should be able to read and write data. For
functions, there's stubs in the procedure linkage table that can
resolve the symbol later because they are functions and can do anything.

I could be wrong about my explanation. If you'd like to learn more
about this topic, one way to do that would be to start with Ulrich
Drepper's articles: https://akkadia.org/drepper/dsohowto.pdf

Best regards,

More information about the R-help mailing list