> Am 26.10.2018 um 18:21 schrieb Thiago Macieira <thiago.macie...@intel.com>: > > On Thursday, 25 October 2018 00:03:32 PDT Roland Winklmeier wrote: >>> The problem might be a number of different things. In general, don't >>> unload >>> libraries. If your design requires it, rethink and redesign. >> >> It was more like a safety feature. Technically I don't have to unload the >> other dlls. I could also keep the previous one loaded, but I was concerned >> about potential conflicts. I'm not an expert in these things, but if there >> are two or even more shared libraries loaded into the same process that are >> almost identical and therefore many common symbol names (the library is >> proprietary so I have no way to check, but the publisher says so) can I run >> into issues? If not, I would not bother unloading them. > > Loading two versions of the same library is even worse and far more likely to > cause problems. When I suggested you redesign, that would be part of it and > you'd need to figure out a way so that you only ever load one and don't > unload > it.
The OP wrote: „Now I would like to add the feature to switch versions at runtime“ It is my understanding that we are talking about 3rd party libraries over which the OP has no source control, so there is nothing to redesign. Also we are talking about „the same library, im different versions“, or in other words: „4.1 being mostly the same as 4.0, but with added features“ (but each implementation in its distinct DLL, of course). I‘m not sure what would happen if you would load those two DLLs (with „mostly the same exported symbol names“): I‘m pretty sure that at link time for sure would get „duplicate symbols“ linker errors. But when using QLibrary? You would explicitly lookup (resolve) the required symbols „by application logic“ (dlopen etc.), and assign them to distinct function pointers etc., so maybe that would even work. (In fact, it /must/ work: for „plugins“ you typically have a „create“ and „destroy“ C-syle function that are dynamically resolved, and of course each such „plugin“ (DLL) has those same function declarations). But I would /still/ want to unload a „plugin“ that is no longer required, especially for „design“ reasons. Why would you want to keep that „dead code“ in memory if the user has decided - at runtime - to use „v4.1“ now instead of the previous 4.0 (or 4.2)? Waste of resources. (The argument „what if the user wants to switch back fast?“ could be solved with a simple QTimer and „5 minutes idle plugins get kicked“ approach). Whether or not the same QLibrary instance can be used to repeatedly load/unload different DLLs I don‘t know: according to Thiago „yes“, and I‘d certainly expect so, too. Cheers, Oliver _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
