[Rd] Finding windows DLLs

[Duncan Temple Lang]

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

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

iD8DBQFHgwIy9p/Jzwa2QP4RAr32AJ9tDRvunOM0RMeCnEPJIlY7s5NgGACfRmK5
yB/ZNnqkdqc2aeu4f6mxW1w=
=kytC
-----END PGP SIGNATURE-----