[Development] Contribution: include separate libraries with inlines in the Qt installers
Dimitar Dobrev
dpldobrev at yahoo.com
Thu Oct 22 20:50:22 CEST 2015
I don't use GetProcAddress but that's beside the point. The point is that any binding, not just mine,
cannot call functions who have not emitted object 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. 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.
On Thursday, October 22, 2015 9:39 PM, Thiago Macieira <thiago.macieira at intel.com> wrote:
On Thursday 22 October 2015 15:10:35 Dimitar Dobrev wrote:
> Host languages need binary symbols to invoke, and in the case of inlines
> those might not be available. About the ABI, that's correct but my idea is
> to have the inlines compiled as part of the Qt build process per platform
> and then included in each installer.
Right, so you have a very, very specialised use-case: you're doing
GetProcAddress for each function and you're using whatever ABI mechanisms you
need to find those functions (note that you *cannot* call __thiscall functions
with MSVC since the "this" parameter is passed in a register).
I don't think we want to ship those extra binaries for such a corner case. No
one else is going to need them.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151022/ee8c2f98/attachment.html>
More information about the Development
mailing list