[Rd] Finding windows DLLs

[Martin Morgan]

Thank you very much, Prof. Ripley, for the prompt solution, and to all
participants in the thread for their insights. Martin

Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:

> 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
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M2 B169
Phone: (206) 667-2793