[Interest] What for does qt5gui need OpenGL?
thiago.macieira at intel.com
Thu Nov 7 18:42:58 CET 2013
On quinta-feira, 7 de novembro de 2013 08:40:03, William Hallatt wrote:
> On 7 November 2013 00:38, Thiago Macieira <thiago.macieira at intel.com> wrote:
> > On quarta-feira, 6 de novembro de 2013 20:12:33,
phil.kursawe at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Interest