Thank you very much, Prof. Ripley, for the prompt solution, and to all participants in the thread for their insights. Martin
Prof Brian Ripley <[EMAIL PROTECTED]> writes: > Let me try to pull the ends together on this. > > - As DTL pointed out one way out is to use a static libxml2. I tried > that, and managed to build and check it under MinGW but it did not work > correctly with package XML. That route used to be possible, but it is > too much work to keep fixing it up, at least for me: package > developers are strongly biased towards providing DLLs on Windows. > > - Renaming the DLL is not an option, as libxml2.dll contains its name, and > if you rename it you will not be able to link against it. Perhaps there > is a route through this involving import libs, but the standard > mechanisms do not work. It also does not solve the dependent DLL > problem. > > - Adding an interface to SetDLLDirectory is viable in Windows > 2000 > provided only one directory is involved. (E.g. not if you want to link > to DLLs provided in another package as well as your own.) I've > implemented that and am about to add it: there is a new argument > 'DLLpath' to dyn.load() and it is set by library.dynam(). This works in > Windows 2000 by temporarily changing the current directory. This > provides a safer way for the Windows' tcltk package to link to its > DLLs. > > Note that the issues are not just confined to Windows: the search path for > dlopen() is pretty much undocumented in most OSes (apart from that > LD_LIBRARY_PATH is involved and it is usually read only at startup). It > usually works because DSOs are versioned and so libxml2.so.2.6.30 is > likely to be found only once (or once for each architecture). Some other > software makes use of ld -R or -rpath (and hence has relocation issues: it > was decided not to consider that for R until libtool was fully usable > which after several years it is not). > > > On Mon, 7 Jan 2008, Prof Brian Ripley wrote: > >> On Mon, 7 Jan 2008, Duncan Murdoch wrote: >> >>> On 1/7/2008 2:51 PM, Martin Morgan wrote: >>>> The XML package relies on libxml2.dll (e.g., bundled with the CRAN >>>> binary) installed in library/XML/libs. Unfortunately, >>>> c:/WINDOWS/system32/libxml2.dll will be found and loaded before >>>> this. >>>> >>>> Is there any programatic solution? >>> >>> Search order for DLLs is version dependent on Windows. The best way to >>> be sure of what you're loading is to fully specify the path to the DLL, >>> and this generally requires you to use API calls LoadLibrary() and >>> GetProcAddress() rather than relying on automatic loading of dependencies. >>> >>> I don't know how many entry points XML is importing from libxml2.dll; if >>> there are a lot, LoadLibrary() will be a pain to use, and it might be >>> easiest to rename libxml2.dll and hope to avoid a collision. >> >> About 85. But it's worse than that, as libxml2.dll itself imports from >> zlib1.dll and iconv.dll, and there is one of the latter in the application >> directory in R >= 2.6.0. So even if you find the right libxml2.dll, you >> may not find the right zlib1.dll and iconv.dll (and I already knew that >> you found R's iconv.dll, which fortunately works). >> >> I think we do need to provide an interface to SetDllDirectory, probably as >> an additional argument to dyn.load. >> >> > > -- > Brian D. Ripley, [EMAIL PROTECTED] > 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 > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M2 B169 Phone: (206) 667-2793 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
