Managing DLLs with the same names in an R session
On Fri, 24 Apr 2009, Patrick Aboyoun wrote:
I am having a problem using two DLLs with the same name, but obviously located in different directories, in an R session. The troublesome package is the (Bioconductor) Rgraphviz package. It relies on (3rd party software) graphviz and imports functions from (Bioconductor) package graph. Unfortunately, the current stable release of graphviz for Windows http://www.graphviz.org/pub/graphviz/stable/windows/graphviz-2.22.2.msi contains a graph.dll in its bin directory. The situation is that Rgraphviz needs to link to the graph.dll from graphviz, E:\paboyoun>..\biocbld\bbs-2.4-bioc\R\bin\R CMD build Rgraphviz [...omitting output...] ** libs making DLL ... [...omitting output...] gcc -shared -s -o Rgraphviz.dll tmp.def LL_funcs.o Rgraphviz.o RgraphvizInit.o agopen.o agread.o agwr ite.o bezier.o buildEdgeList.o buildNodeList.o doLayout.o graphvizVersion.o init.o -LC:/Graphviz2.22/ bin -lgvc -lgraph -lcdt -Le:/biocbld/bbs-2.4-bioc/R/bin -lR [...omitting output...] but at run time R dispatches to the graph.dll from the graph package to resolve the symbols. R-2.9> Sys.which("graph.dll") graph.dll "C:\\GRAPHV~1.22\\bin\\graph.dll" R-2.9> library(Rgraphviz) Loading required package: graph Loading required package: grid << Message box appears: The procedure entry point agclose could not be located in the dynamic link library graph.dll >> Running Rterm.exe through the DependencyWalker software, I see that the gvc.dll and cdt.dll graphviz libraries are properly loaded, but the graph.dll dependency of Rgraphviz.dll links to the graph.dll library from the graph package. I tried passing the DLLpath for graphviz to the library.dynam function call when loading Rgraphviz.dll in the .onLoad function within Rgraphviz and it had no effect. I also tried library.dynam.unload/dyn.unload-ing the graph.dll from the graph package and then loading the Rgraphviz.dll followed by the reloading of the graph.dll from the graph package and the graph.dll dependencies become broken to the point that a call out to a graph.dll results in a GPF. Is is possible to manage DLLs with the same name from R or do I need to rename one of the DLL names to make them unique?
On Windows, the latter is the only completely reliable solution that we know of. We've been here with iconv.dll, and had to rename the R copy to Riconv.dll as a result. (Unfortunately, it depends on the version of Windows and even the service pack installed. AFAICS some versions of Windows only allow one DLL of a given name to be loaded by a single process, here the R process.) There are (older?) Unix-alike OSes with similar issues.
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595