On quinta-feira, 7 de novembro de 2013 08:40:03, William Hallatt wrote: > On 7 November 2013 00:38, Thiago Macieira <thiago.macie...@intel.com> wrote: > > On quarta-feira, 6 de novembro de 2013 20:12:33, phil.kursawe@gmail.comwrote: > > > I see. I thought Qt renders using the system natively. It could load > > > > opengl > > > > > like it loads SSL support, dynamically. > > > > That's a solution we really dislike. > > Would you mind explaining why? My knowledge of this level of design is > virtually non-existent so your input would be hugely appreciated (even if > you can just provide me with a few related key words so that I may research > the concepts that influenced the design decision myself).
Dynamic loading a library requires that we write the code to find the library to be loaded. That's extra code that we need to write, duplicating what the dynamic loader already has. Unlike plugins, libraries can be anywhere in the system. Also, libraries on Unix systems have version numbers attached to the file names and we have to know *which* number to find. For example, for libudev, we need to scan for both libudev.so.0 and libudev.so.1. That means we, the developers, need to guess what the system has. We can't indiscriminately load any number, since we don't know whether libudev.so.2 will retain compatibility. Dynamic loading also requires that we provide fallback code, if the library we request is missing. That's because dynamic loading does not write a requirement into the library's header, which packaging tools know to look for. For the libudev case, we had to ensure that QtSerialPort has fallback in case it can't use udev to find the serial ports. For SSL support, we transferred the to the users: you *have* to check if QSslSocket::supportsSsl() returns true before you start using SSL. Another drawback is that it generates worse code. Unless we start writing assembly by hand, per platform, our finding and calling of functions in loaded libraries is not going to be as efficient as the one generated by the compiler and linker. We've done both solutions that search for all functions at startup (SSL), which in turn means we have a load-time impact searching for functions that may or may not ever be used; and we have solutions that do lazy lookups (D-Bus), but then the application has no graceful way to fail if a function is missing at runtime: it can only crash. There's also an issue of thread-safety: libraries properly linked to get loaded and initialised before the application reaches main(), which means no threads are running. Libraries dynamically loaded may be loaded into the application while multiple threads are running. Some libraries may not like being accessed from multiple threads. And then there's the question of when to unload them. We have to figure out when to unload those libraries by ourselves. I did a lot of work to rewrite the QLibrary static unloader in Qt 5.2 and, trust me, it was not easy. Moreover, we may end up unloading a library from QtCore's global destructors before another global destructor gets run, one that still requires the library. Our best bet would be to actually leak the loaded libraries. Finally, on platforms that make use of prelinking, libraries only loaded through dynamic loading will, at best, not be prelinked. At worst, it will actually have been prelinked to the wrong address and cause a pessimisation. So, in all, I will oppose any use of dynamic loading of libraries. I will accept only when we're forced to, like udev and OpenSSL. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
