[Rd] Finding windows DLLs

[Prof Brian Ripley]

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,                  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