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
