UPDATE
The environment variable which causes the issue is QT_PLUGIN_PATH
being exported system-wide at the time of user login.
I have a variety of Qt applications where having QT_PLUGIN_PATH
set is not an issue. So, this Fritzing 0.9.3b non-launch behavior was a surprise.
One would expect that the application's executable path and/or qt.conf
included in the application bundle would take precedence over QT_PLUGIN_PATH
.
When the application is run, Qt will first treat the application's executable directory as the base directory for searching for plugins.
See Qt Documentation > Deploying Plugins
An alternate (maybe more robust) strategy might be to use QCoreApplication::addLibraryPath()
or QCoreApplication::setLibraryPath()
.
However, I also learned that this note has been added to the Qt documentation ...
QT_PLUGIN_PATH
should not be exported as a system-wide environment variable since it can interfere with other Qt installations.
So, while Fritzing might have ways to launch more robustly in the presence of QT_PLUGIN_PATH
being preset, the user (like my situation) can also resolve the issue by not setting QT_PLUGIN_PATH
as a system-wide variable.
Cheers.