[Development] Contribution: include separate libraries with inlines in the Qt installers

[Thiago Macieira]

On Thursday 22 October 2015 18:50:22 Dimitar Dobrev wrote:
>     I don't use GetProcAddress but that's beside the point. 

Actually, that is entirely the point. And yes, you do. Doesn't matter if you 
use it directly or not, that's how on Windows you obtain the address of 
symbols. I'm talking about Windows because the example you gave had Windows-
specific flags like LIBS += -lole32. On other systems, that would be dlsym.

Unless you've replaced the entire loading of binaries and you have your own 
ELF/Mach-O/PE-COFF parser. Then you're not using GetProcAddress/dlsym, but 
have an equivalent that does exactly the same thing.

>     The point is
> that any binding, not just mine, cannot call functions who have not emitted
> object code. 

Correct, if we assume the binding does GetProcAddress/dlsym and uses libffi to 
place the call.

But that's a generalisation. There are bindings that don't do that and simply 
generate the inlines they need when they compile against the source code.

> In other words, the shipped Qt binaries contain a set of
> functions that can only be invoked by C++ and nothing else. So I wouldn't
> call it a very specialised use case.

I still would. Qt is a C++ framework, so anything that is not C++ is a 
specialised use-case.

Note that using the binding isn't the use-case we're talking about here. We're 
talking about *building* the binding itself, which only a dozen people in the 
entire world do.

> The reason nobody else has asked for
> it so far is that each binding deals with it on its own, usually by
> generating an additional C layer over Qt which layer has the inlines
> compiled in. However, I believe the problem is common to all bindings so a
> Qt add-on to contain these symbols would definitely be useful.

And I think the way those other bindings have done it is the correct way. 
Using GetProcAddress/dlsym plus libffi to call C++ functions is too fragile 
and specialised for us to support.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center