macdeployqt does not properly remap libs?

Dariusz

Hey

I'm trying to figure out why macdeploy skips half of the dependencies in my app and why despite dylib being in the file is not being found by other libs...
I've started going over all files in my bundle and running otool -L on them.
I noticed some strange things, some libs were not remapped properly to usen executable folder:

appTest.app/Contents/MacOS/appTest:
	@rpath/QtNetwork.framework/Versions/A/QtNetwork (compatibility version 6.0.0, current version 6.3.0)
	@rpath/QtConcurrent.framework/Versions/A/QtConcurrent (compatibility version 6.0.0, current version 6.3.0)
	@rpath/QtOpenGLWidgets.framework/Versions/A/QtOpenGLWidgets (compatibility version 6.0.0, current version 6.3.0)
	/opt/homebrew/opt/openimageio/lib/libOpenImageIO.2.3.dylib (compatibility version 2.3.0, current version 2.3.16)
	/opt/homebrew/opt/openimageio/lib/libOpenImageIO_Util.2.3.dylib (compatibility version 2.3.0, current version 2.3.16)
	/opt/homebrew/opt/imath/lib/libImath-3_1.29.dylib (compatibility version 29.0.0, current version 29.4.0)
	@rpath/QtWidgets.framework/Versions/A/QtWidgets (compatibility version 6.0.0, current version 6.3.0)
	@rpath/QtOpenGL.framework/Versions/A/QtOpenGL (compatibility version 6.0.0, current version 6.3.0)
	@rpath/QtGui.framework/Versions/A/QtGui (compatibility version 6.0.0, current version 6.3.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)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2113.40.126)
	/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 261.13.0)
	@rpath/QtCore.framework/Versions/A/QtCore (compatibility version 6.0.0, current version 6.3.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)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1300.23.0)

I'm having /opt/homebrew/opt/openimageio/lib/libOpenImageIO.2.3.dylib on quite a few dylib's and main app executable...
Is this a bug? Or how should I tell it to remap it?
He did copy the dylib properly to contents/frameworks/xx.dylib, but he did not link against it...
any ideas? My own dylib that I generate gets linked properly, but the file above does not.

I'm also having issue with this one :

testApp.app/Contents/Frameworks/libavformat.58.dylib:
	@executable_path/../Frameworks/libavformat.58.dylib (compatibility version 58.0.0, current version 58.76.100)
	/opt/homebrew/Cellar/ffmpeg@4/4.4.2_2/lib/libavcodec.58.dylib (compatibility version 58.0.0, current version 58.134.100)
	/opt/homebrew/Cellar/ffmpeg@4/4.4.2_2/lib/libswresample.3.dylib (compatibility version 3.0.0, current version 3.9.100)

Hes linking against /opt/homebrew instead of the one copied to frameworks ?

It looks that anything that comes via brew find_packages is not linked properly, and anything that comes through it is not recursively iterated. Say if I include OpenImageIO, that includes libavformat that includes libswresample then libavcodec does not get remapped properly for libswresample?

I'm about to write python script to re-link everything, but I have a feeling that this should be recursively all re-linked to proper project-relative-location path...?

Dariusz

Ok I got it working.
To suimmarize
macdeployqt did not relink all files properly. In order to fix it I ended up

Loop over all frameworks in my bundle
otool -chant oldPath newPath targetDylib file
codesign --force --timestamp --sign "FSDVASDVASDVASVSA" dylibPath

codesign stamp taken from security find-identity -v -p codesigning

I looped over frameworks 1st, then extra libs, then target executable at the end. Apparently all this has to happen in order.
After that both ARM and Intel build start.
ARM is very sensitive with code signing apparently. Hope this helps the next poor soul wanted to use cmake on mac.

EDIT1.
There is more to this answer...
Once. you re-path the dylibs... then you need to sign them, ideally with -option runtime. Then you need zip it all and send to apple for notarization... there is WWDC talk in 2019 that introduces the concept/explains why and in 2021 (I think) another video that shows new APi to do it all in 1 command. - well mostly.
In any case you need to notarize ur app & then stamp. So that any mac can run it without warning... lots of FUN TIME APPPLE. But at least its provided by apple and work nicely as opposed to Microsoft signing bananas ;/// Microsoft u officially sux.