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, [EMAIL PROTECTED] 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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
