[Rd] Finding windows DLLs

[Prof Brian Ripley]

On Tue, 8 Jan 2008, Duncan Temple Lang wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> While I don't disagree with the general need to provide an interface
> to SetDllDirectory, etc., I think the discussion about 3rd party
> libraries has slightly missed the more obvious solution.
> Instead of using a DLL, such packages can link against a _static_
> version of the 3rd party and so not get into this dynamic search and
> load but guarantee that the symbols are resolved to what they were
> intended at build time.

Only if there is one.  This has been my practice when building Windows 
binary packages, but as in the recent example of ncdf, the developers of 
the third-party (netcdf) set up their make system only to implement some 
Windows tweaks when a DLL was built.  More commonly, the third-party has 
to be built under a different compiler (typically VC++), and the static 
library is not compatible with MinGW.  (iconv and Tcl/Tk are two examples 
where at least at one time MinGW builds didn't work correctly.)

In the case of XML, we could revert to my practice before Uwe took over, 
as I did (after some struggle) build libxml2/zlib statically under older 
versions of MinGW and so would expect to be able to do so again.

> There are lots of advantages to using DLLs, but in many cases
> we are not exploiting these and a static link would make these
> issues irrelevant and not require users to know about PATH settings, etc.
>
> D.
>
>
> 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