[Rd] Finding windows DLLs

[Duncan Temple Lang]

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

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