dokany
dokany copied to clipboard
dokan-dev
Library - Static linking
Description
Dokany's license permits static linking but it isn't designed to be used as a static library out of the box. The library defines DllMain function which causes multiple definition of that symbol if the library is statically linked to another DLL. Apart from that there doesn't seems to any other obstacle to static linking.
As a possible solution I suggest to add some preprocessor constant like DOKAN_STATIC_LINKING. When it's defined the library will not define the DllMain function at all allowing user's DLL to provide its own. In v2.0 the DllMain is empty and doesn't do anything. In v1.3 it performs initialization and shutdown procedure. Then we need to move DllMain's code to another function (let's call it DllMainRoutine) callable by the user in its own DllMain (or any other place to perform initialization and shutdown) and make Dokany's DllMain (when it's defined) to call that DllMainRoutine.
Should I make a pull request with such changes or there is something else I should consider when I link Dokany statically?
Hi @KerberX ,
Yes, we can make dokan library dynamic and static with a preprocessor constant as you explained. We should well document DllMainRoutine to make the user well understand he needs to call it before any dokan usage 👍
I just wonder if there is a clean way to have both build in VS without extra platform or something like that. Just have both generated in the same time.
Dokany's license permits static linking
Yes but...IANAL... but as far as I see it, you can statically link Dokany (or any other LGPL licensed lib), but then you will have to supply object files of your app so that users can link a modified version of Dokany against your app. At this point I am wondering why you want to do this, given that shipping a DLL is easier than shipping the statically linked executable plus the object files.
See https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic and consult a lawyer.
Sorry but what is "IANAL"?
My use case is the following. I statically link Dokany to my own DLL (also LGPL) and that DLL is used in the final product. I don't ship original object files of Dokany or object files of my DLL with the final app. The user can always build them, source code is provided.
@Rondom I agree dynamic is always going to be the mainstream usage. Just having the code ready for anyone look to static link could not hurt if they follow the license.
That's why should we really need to enable static build and include it in installer? Would it have helped you?
Unfortunately, static build will double (at best) the amount of VS build configurations. I'm not sure about including it in the installer. Static lib isn't needed by users installing Dokany for the application they're using. For development it's probably preferable to download the source and compile it (especially because Doknay compiles just fine without tweaking on user's machine).
@KerberX Alright so we could just have the changes of dllmain and the define well documented for having dokan user easily the possibility to use it static without providing the build configuration.
Yeah. If anyone wants to link statically s/he probably knows what to change in VS options. Though it also could be documented as it's only two options (if you count /MT-/MD).
There's one more thing I forgot about. The _EXPORTING macro constant which controls import/export specification and definition of DOKANAPI and DOKAN_API macros (why there are two of them?). This _EXPORTING macro should defined when DOKAN_STATIC_LINKING is defined.