[mythtv-commits] Ticket #9447: MacOS X - Qt binaries log spam
MythTV
noreply at mythtv.org
Fri Mar 2 18:12:21 UTC 2012
#9447: MacOS X - Qt binaries log spam
-------------------------------------------------+-------------------------
Reporter: Craig Treleaven <ctreleaven@…> | Owner:
Type: Bug Report | jyavenard
Priority: minor | Status:
Component: Ports - OSX | assigned
Severity: medium | Milestone: unknown
Keywords: | Version:
| 0.24-fixes
| Resolution:
| Ticket locked: 0
-------------------------------------------------+-------------------------
Comment (by mythtv@…):
Hi Nigel,
No problem.
The `dvbdescriptors.cpp` changes are key, without them Qt will not detect
the presence of a `qt.conf` file and will not modify its paths
accordingly. I entirely understand your reticence over this change,
perhaps you could get someone more familiar with the `dvbdescriptors.cpp`
code to review/make it?
`libqgif.dylib` and `libqjpeg.dylib` are not the only Qt plugins required.
We are definitely using the text codecs, which live beneath `.osx-
packager/build/plugins/codecs`. I am unsure as to whether any other
plugins are required; But I would suggest the drawbacks associated with
the possibility of someone introducing new code that requires the services
of hitherto unused plugins outweighs any potential benefits associated
with not including them all within the application bundles.
Any plugins we do load must be processed by `osx-bundler.pl` in order to
have the references to the Qt dynamic libraries that are embedded within
them rewritten from pointing to the Qt libraries in `.osx-
packager/build/lib` so that they point to the libraries within
`<app_bundle>/Contents/Resources`. Failure to do this results in the
application, which has been processed by `osx-bundler.pl`, loading
`<app_bundle>/Contents/Resources/qtcore.dylib`, then later a plugin which
references `.osx-packager/build/lib/qtcore.dylib`. The dynamic linker does
not understand that these are the same libraries and therefore loads two
copies of `qtcore.dylib` into memory. Resulting in two sets of global
variables, Qt threads running, etc. which ultimately leads to lots of log
spam and probably some form a application crash.
The presence of an empty `<app_bundle>/Contents/Resources/qt.conf` in an
application bundle containing Qt libraries when `QLibraryInfo` is
initialised after `QCoreApplication` causes Qt to adjust its default paths
as described in [[https://qt-project.org/doc/qt-4.8/qt-conf.html|Using
qt.conf]]. Having reviewed it I realise that I have not validated that the
plugins copied to `<app_bundle>/Contents/Resources/plugins` by my changes
to `osx-packager.pl` are actually being loaded. All I have validated is
that the changes to `dvbdescriptors.cpp` are required to get Qt to
recognise the presence of `<app_bundle>/Contents/Resources/qt.conf` and
that with a `qt.conf` present, Qt will not load the plugins from `.osx-
packager/build/plugins` therefore preventing the log spam/crash.
Re-reading the [[https://qt-project.org/doc/qt-4.8/qt-conf.html|qt.conf]]
documentation suggests that we both may be wrong. I now believe that the
plugins should all be placed beneath `<app_bundle>/Contents/MacOS/plugins`
(i.e. the image format plugins belong beneath
`<app_bundle>/Contents/MacOS/plugins/imageformats`), because
`<app_bundle>/Contents/MacOS` is the equivalent of
`QCoreApplication::applicationDirPath()`? But we can put the plugins
wherever we wish as long as we add a `Plugins = <directory>` entry beneath
the `[Paths]` section within the `qt.conf` file.
Indeed `Syscall("touch $res/qt.conf")` would probably suffice, my proposal
is based upon a combination of “''when in Perl, do as Perl''” and the fact
that we may wish to actually write some information into the `qt.conf`
file in the future (e.g. customise the `Plugins` path).
Thanks
Peter
--
Ticket URL: <http://code.mythtv.org/trac/ticket/9447#comment:11>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center
More information about the mythtv-commits
mailing list