[Development] Contribution: include separate libraries with inlines in the Qt installers
Thiago Macieira
thiago.macieira at intel.com
Fri Oct 23 00:19:43 CEST 2015
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
More information about the Development
mailing list