Date: Thu, 7 Nov 2024 20:07:06 -0600
> It's far easier to query some metadata
Definitely agreed on that
Jeremy
On Thu, Nov 7, 2024 at 6:48 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Thursday 7 November 2024 13:53:43 Pacific Standard Time Jeremy Rifkin via
> Std-Proposals wrote:
> > Does it have to be prior to the load? What’s wrong with loading it as long
> > as you don’t use stdlib constructs across ABI boundary until after
> > verifying some match?
>
> By your *strict* answer, that would work. But the devil will be in the
> details.
>
> You said "don't use stdlib constructs across ABI boundary". That means the
> plugin MUST NOT make any function calls using the stdlib types to any function
> that may reside in another DLL/library, before the verification is made. This
> includes any and all static initialisation content (global constructors).
> Worse, this applies to any library the plugin may have linked to which may
> potentially not yet have been loaded into memory by the host application or
> library.
>
> The only way to be certain of this is to have a strict requirement of
> "absolutely no load-time constructors" and this must apply transitively to all
> C++ libraries you link to. The barrier for this is pretty high, considering
> you may not control the content of said libraries and you may not even be
> distributing them.
>
> It's far easier to query some metadata. Your plugin system can simply install
> a file next to the plugin with the information you need. This comes in handy
> too to find out the plugin's capabilities and decide at runtime whether you
> want it or not. KDE software using Qt 1 to 4 did that with a .desktop file next
> to the plugins.
>
> Starting with Qt 5, the Qt plugin mechanism allows you to specify a JSON file
> that will be parsed by moc and added to the Qt metadata information in the in
> the binary itself. See https://doc.qt.io/qt-6/qpluginloader.html#metaData and
> https://doc.qt.io/qt-6/qtplugin.html#Q_PLUGIN_METADATA.
>
> We even have a tool (qtplugininfo) that you can use to query that.
>
> $ qtplugininfo $PWD/plugins/platforms/libq{xcb,wayland-generic}.*
> libqxcb.t.so: IID "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.
> 5.3" Qt 6.9.0 (release)
> User Data: {
> "Keys": [
> "xcb"
> ]
> }
> libqwayland-generic.t.so: IID "org.qt-
> project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3" Qt 6.9.0 (release)
> User Data: {
> "Keys": [
> "wayland"
> ]
> }
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Definitely agreed on that
Jeremy
On Thu, Nov 7, 2024 at 6:48 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Thursday 7 November 2024 13:53:43 Pacific Standard Time Jeremy Rifkin via
> Std-Proposals wrote:
> > Does it have to be prior to the load? What’s wrong with loading it as long
> > as you don’t use stdlib constructs across ABI boundary until after
> > verifying some match?
>
> By your *strict* answer, that would work. But the devil will be in the
> details.
>
> You said "don't use stdlib constructs across ABI boundary". That means the
> plugin MUST NOT make any function calls using the stdlib types to any function
> that may reside in another DLL/library, before the verification is made. This
> includes any and all static initialisation content (global constructors).
> Worse, this applies to any library the plugin may have linked to which may
> potentially not yet have been loaded into memory by the host application or
> library.
>
> The only way to be certain of this is to have a strict requirement of
> "absolutely no load-time constructors" and this must apply transitively to all
> C++ libraries you link to. The barrier for this is pretty high, considering
> you may not control the content of said libraries and you may not even be
> distributing them.
>
> It's far easier to query some metadata. Your plugin system can simply install
> a file next to the plugin with the information you need. This comes in handy
> too to find out the plugin's capabilities and decide at runtime whether you
> want it or not. KDE software using Qt 1 to 4 did that with a .desktop file next
> to the plugins.
>
> Starting with Qt 5, the Qt plugin mechanism allows you to specify a JSON file
> that will be parsed by moc and added to the Qt metadata information in the in
> the binary itself. See https://doc.qt.io/qt-6/qpluginloader.html#metaData and
> https://doc.qt.io/qt-6/qtplugin.html#Q_PLUGIN_METADATA.
>
> We even have a tool (qtplugininfo) that you can use to query that.
>
> $ qtplugininfo $PWD/plugins/platforms/libq{xcb,wayland-generic}.*
> libqxcb.t.so: IID "org.qt-project.Qt.QPA.QPlatformIntegrationFactoryInterface.
> 5.3" Qt 6.9.0 (release)
> User Data: {
> "Keys": [
> "xcb"
> ]
> }
> libqwayland-generic.t.so: IID "org.qt-
> project.Qt.QPA.QPlatformIntegrationFactoryInterface.5.3" Qt 6.9.0 (release)
> User Data: {
> "Keys": [
> "wayland"
> ]
> }
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-11-08 02:07:23