Application delivered via the macOS or iOS App Store might have their libraries encrypted, in which case we can not read any of the sections of the binary until it has been dlopened. This was causing issues for our plugin loading code, which assumed we could read the .qtmetadata section of a yet to be loaded plugin to determine its suitability, before loading it. We now detect whether a library is encrypted during the Mach-O parsing, and propagate this back to QLibraryPrivate::updatePluginState(), which can handle the case by explicitly loading the library before continuing with metadata validation. We still ensure that the library has a .qtmetadata section, so that we don't need to dlopen any random library in our path. This does mean that we will potentially load more plugins than we need, and since the Qt version validation happens as part of meta data validation, we might dlopen() incompatible plugins, but it's expected that in an App Store deployment scenario you control both the versioning and set of shipped plugins, so this should not be an issue in practice. As encrypted libraries are only produced for apps that are fully published to the App Store, and then deployed via MDM, VPP, or Apple Configurator 2, we don't have an easy way to test this, but the existing code paths should be unaffected, and hopefully this patch improves the situation for the encrypted library case. Pick-to: 6.5 6.4 6.2 5.15 Change-Id: Iff733505f7067ce5571854ea978bc95e8376e347 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>