Fritzing 0.9.3b fails to launch with its built-in Qt framework

bugs
1

Steps I took that resulted in the problem:

  1. Rename existing Fritzing.app (version 0.9.2b) so existing application would not be overwritten.

  2. Drag & Drop install Fritzing.app version 0.9.3b to /Applications directory.

  3. Control-Click launch to expressly OK gatekeeper to allow launch. Also, normal Double-Click to launch.

LAUNCH FAILS

Apple alert indicates “Fritzing quit unexpectedly. … send a report to Apple.”

  1. Try launch from Terminal command line:
cd /Applications/Fritzing.app/Contents/MacOS
./Fritzing

LAUNCH FAILS

This application failed to start because it could not find or load the Qt platform plugin “cocoa” in “”.

Available platform plugins are: cocoa, minimal, offscreen, cocoa.

Reinstalling the application may fix this problem.
abort ./Fritzing

  1. Try launch again from Terminal command line with more environment control:
unset QT5_MODULE_PATH
unset QT5_PATH
unset QT_PLUGIN_PATH
export PATH=_no_reference_to_any_qt_installation_
cd /Applications/Fritzing.app/Contents/MacOS
./Fritzing

LAUNCH OK :slight_smile:

What I expected should have happened instead:

The Fritzing.app itself contains the required Qt framework libraries (.dylib, etc.). I would expect Fritzing 0.9.3b to launch OK with a standard user double click … by using the Qt libraries self contained within Fritzing.

Fritzing 0.9.3b should be able to launch OK (like 0.9.2b) without the need to unset any environment variables.

My version of Fritzing and my operating system:

  • Fritzing 0.9.2b and 0.9.3b
  • Mac OS X El Capitan
  • Qt Creator 4.0.1 / Qt Framework 5.6.1
  • Environment variables set to support Qt development projects: QT5_MODULE_PATH, QT5_PATH, QT_PLUGIN_PATH, and PATH

Please also attach any files that help explaining this problem

2

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.