On 2 December 2013 06:05, Martin Nowak <c...@dawg.eu> wrote: > On 11/18/2013 06:12 AM, Walter Bright wrote: > >> >> I'm very much against the suggested rewriting of obj files to strip the >> export records :-) >> > > That is only one particular aspect of the DIP. It's not essential and > maybe we'll find a different solution during implementation. > The need to statically link a library into a DLL is rare enough to > delegate this to an extra tool. >
Sorry, I'm just casually following this thread. I'm very interested to have this mess resolved, but don't have a great deal of input. This comment surprised me a little though, you say it's rare to statically link a lib into a DLL? In my experience, I don't think that's rare at all, I'd say it's very common, in fact, in my experience, I can't think of many instances where I've built some code as a DLL which hasn't included other lib's (statically linked). Maybe it's just me, but if I'm building something as a DLL (rather than a static lib), it's precisely because it is quite large, and offers generally self-contained functionality (which often depends on other libs). The only exception in my experience is plugin functionality. Just a comment on other aspects of this thread... There's all this debate around dllimport vs dllexport. And this is probably my ignorance, but I have to wonder why dllimport even exists? I've been using DLL's for a long time, and I've never used dllimport (that I'm aware of). I either statically link an import lib (which binds to the exports in a nice efficient way), or I call LoadLibrary and find symbols manually... I'm not really even sure what dllimport does. Why is it so important, and why is it causing so much fuss?
