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."?

bweir

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)

SGaist

Hi,

That generally means that you have one of the dependencies linked to another version of Qt. Are you using any third party library ?

bweir

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 use qmake. 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 run brew 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 running macdeployqt.

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 or dyld 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?

hskoglund

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)

bweir

@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?

hskoglund

Yeah could be, because you're only running macdeployqt once for both programs, right?

bweir

@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 calls macdeployqt /path/to/bundle.app/ -executable=/path/to/bundle.app/Contents/MacOS/$f for each f.

    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.