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