[Interest] What for does qt5gui need OpenGL?

[Thiago Macieira]

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...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131107/065cd673/attachment.sig>