Hi, Patrick, We have ported Rgraphviz to Win64, and we had the same issue. Basically we have to compile graphviz from the scratch (because there is no graphviz binaries on Win64) and rename graph.dll to graphviz-graph.dll.
Thanks, Alex On Fri, Apr 24, 2009 at 11:07 AM, Patrick Aboyoun <paboy...@fhcrc.org>wrote: > Thanks Brian. I'll stop trying to hack the code to work and opt for the dll > rename option. > > Patrick > > > > Prof Brian Ripley wrote: > >> 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. >> >> > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Alex Chen, Ph.D. Software Engineer & Research Scientist REvolution Computing 1100 Dexter Avenue N, Suite 250 Seattle, WA 98109 P: 206-577-4778 x3209 | www.revolution-computing.com [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
