[Rd] Finding windows DLLs

[Prof Brian Ripley]

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Prof Brian Ripley wrote:
>> 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.
>
> I assume 'one' refers to DLLs.
> Either way, of course you can link against static versions of all
> libraries and not just one. It requires having static versions of each
> library.

It refers to 'a _static_ version': normal English rules -- the immediate 
antecedent -- apply.

>> 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.
>
> Well this is the issue - whether we want to build our own versions of
> a static version of a DLL.  It would be a lot better if Windows users
> were aware of the work done to support them and realized that it reduced
> the resources available for more creative work.
>
>
>
>>> 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.
>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHgxrn9p/Jzwa2QP4RAnsVAJsEkOT7DEu3pIOkIiA23RZ9mACIfACeIqrG
> L3YrWfoD916Vbzu1zy93KkU=
> =6yOz
> -----END PGP SIGNATURE-----
>

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