[Interest] What for does qt5gui need OpenGL?

[William Hallatt]

On 7 November 2013 19:42, Thiago Macieira <thiago.macieira at intel.com> wrote:

> 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
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
Hi Thiago,

Thank you very much for taking the time out to write that up.  I appreciate
it immensely!

Have a great weekend,
William.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131108/75218ab2/attachment.html>