Homebrew Qt5 and macdeployqt: "Class NotificationReceiver is implemented in both /Users/.../QtWidgets and /usr/local/Cellar/.../QtWidgets. One of the two will be used. Which one is undefined."?
-
I am at a loss as to how to make this message stop. Is there something strange about Homebrew in how it installs Qt5? What is the definitive way to ensure that an app bundle doesn't look in system locations for a framework? Any ideas?
$ ./propelleride objc[30105]: Class NotificationReceiver is implemented in both /Users/brett/Projects/PropellerIDE/build/staging/mac/PropellerIDE.app/Contents/Frameworks/QtWidgets.framework/Versions/5/QtWidgets and /usr/local/Cellar/qt5/5.5.0/lib/QtWidgets.framework/QtWidgets. One of the two will be used. Which one is undefined. QCoreApplication::arguments: Please instantiate the QApplication object first QCommandLineParser: argument list cannot be empty, it should contain at least the executable name $ otool -L * bstc (architecture i386): bstc (architecture ppc): bstl (architecture i386): /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.6) bstl (architecture ppc): /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.6) openspin: @loader_path/../Frameworks/QtGui.framework/Versions/5/QtGui (compatibility version 5.5.0, current version 5.5.0) @loader_path/../Frameworks/QtCore.framework/Versions/5/QtCore (compatibility version 5.5.0, current version 5.5.0) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) propelleride: /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1153.18.0) @loader_path/../Frameworks/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.5.0, current version 5.5.0) @loader_path/../Frameworks/QtGui.framework/Versions/5/QtGui (compatibility version 5.5.0, current version 5.5.0) @loader_path/../Frameworks/QtCore.framework/Versions/5/QtCore (compatibility version 5.5.0, current version 5.5.0) /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0) @loader_path/../Frameworks/QtSerialPort.framework/Versions/5/QtSerialPort (compatibility version 5.5.0, current version 5.5.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
-
Hi,
That generally means that you have one of the dependencies linked to another version of Qt. Are you using any third party library ?
-
Hi there, @SGaist, thanks for the speedy reply. :)
No third party libraries. I had used Homebrew to install Qt5 on my Mac. The version it installs is 5.5.0. It isn't available in the path, so I have to add
export PATH=/usr/local/opt/qt5/bin:$PATH
to.bash_profile
in order to useqmake
. So far so good.So my build system uses
macdeployqt
to install the Qt5 libraries from the system (the only ones installed are from Homebrew) into the app bundle. I go to run my application and it will not start. If I runbrew uninstall qt5
and remove it from the system, my app will run. It's almost as if the Homebrew Qt5 build has the path to its own location in Homebrew hard-coded into it, so that the old location remains even after runningmacdeployqt
.But then, I thought that was the point of
macdeployqt
in the first place: to isolate the deployed Qt5 framework. Even if that's not the case, one library is just a copy of the other, so why wouldn't Qt ordyld
or whatever application just go with the first Qt5 it finds in the uhh... framework path. For that matter, is there a concept of a system library path on OS X?I ended up getting sidestepping the problem by building Qt myself, but even so, I can't have Homebrew's Qt installed on the system otherwise this problem comes back. I never saw this issue until I started using Homebrew, which I needed to use Travis CI for building my software.
I can't figure out if there is something I've overlooked in how I'm deploying it, or there is something weird about how the Homebrew version is packaged, but I'm not even really sure what I'm looking for. Any ideas?
-
Hi, if propelleride loads openspin (just guessing) then you could try adding
QT += widgets
to openspin's .pro file (so that both propelleride and openspin loads the same # of Qt frameworks) -
@hskoglund Ahh, propelleride and openspin are actually their own standalone executables. Perhaps
macdeployqt
is doing something funky since I'm putting them into the same bundle? -
Yeah could be, because you're only running
macdeployqt
once for both programs, right? -
@hskoglund nope, here's what happens. I've been writing a tool called packthing that among other build systems, automates packaging of Qt software. Here's the link if you wanna check it out. =P
Anyway, at this point,
packthing.builders.qmake
has a list of Qt executables in self.files['bin'] and callsmacdeployqt /path/to/bundle.app/ -executable=/path/to/bundle.app/Contents/MacOS/$f
for eachf
.def dmg(self, path): print self.files['bin'] for f in self.files['bin']: fn = os.path.basename(f) subprocess.check_call([ 'macdeployqt', path, '-executable='+os.path.join(path,"Contents","MacOS",fn) ])
The thing is, I've never had a problem before Homebrew was installed. When I used the Qt online installer, there were never any conflicts with private frameworks. I can't imagine what could be different about the Homebrew Qt.