In versions of R prior to 3.0, by default .C and .Call would find the requested C function regardless of which shared library it was located in. You could use the PACKAGE argument to restrict the search to a specific library, but doing so was not necessary for it to work.
R 3.0 introduced a significant change to that behavior; from the NEWS file: CHANGES IN R 3.0.0: PERFORMANCE IMPROVEMENTS: * A foreign function call (.C() etc) in a package without a PACKAGE argument will only look in the first DLL specified in the NAMESPACE file of the package rather than searching all loaded DLLs. A few packages needed PACKAGE arguments added. That is not merely a performance improvement, it is a significant change in functionality. Now, when R code in my package foo tries to call C code located in bar.so, it fails with a "not resolved from current namespace (foo)" error. It works if I change all my uses of .C and .Call to pass a PACKAGE="bar" argument. Ok, I can make that change in my code, no big deal. What surprises me though, is that there appears to be no way to invoke the old (and very conventional Unix-style), "I don't want to specify where the function is located, just keep searching until you find it" behavior. Is there really no way to do that, and if so, why not? Comparing the R sources on the 3.1 vs. 2.15 branches, it looks as if this is due to some simple changes to resolveNativeRoutine in "src/main/dotcode.c". Specifically, the newer code adds this: errorcall(call, "\"%s\" not resolved from current namespace (%s)", buf, ns); And removes these lines: /* need to continue if the namespace search failed */ *fun = R_FindSymbol(buf, dll.DLLname, symbol); if (*fun) return args; Is that extra call to R_FindSymbol really all that's necessary to invoke the old "keep searching" behavior? Would it be a good idea to provide an optional way of finding a native routine regardless of where it's located, perhaps via an optional PACKAGE=NA argument to .C, .Call, etc.? And now I see that help(".Call") says: 'PACKAGE = ""' used to be accepted (but was undocumented): it is now an error. I assume passing PACKAGE="" used to invoke the same "keep searching" behavior as not passing any PACKAGE argument at all. So apparently the removal of functionality was intentional. I'd like to better understand why. Why should that be an error? Or said another way, why has traditional Unix-style symbol resolution been banned from use with .C and .Call ? -- Andrew Piskorski <a...@piskorski.com> ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel