[macOS] packaging error at opening: cannot load library, no plugins at all

[mathildemerle]

At launch of the macOS binary, there are no plugins including those from medInria and our external project:

WARN - Wed Oct 19 14:20:44 2022 - "Unable to load /Applications/MUSICardio 2.app/Contents/PlugIns/libmedItkArithmeticOperationProcessPlugin.dylib - Cannot load library /Applications/MUSICardio 2.app/Contents/PlugIns/libmedItkArithmeticOperationProcessPlugin.dylib: (dlopen(/Applications/MUSICardio 2.app/Contents/PlugIns/libmedItkArithmeticOperationProcessPlugin.dylib, 0x0009): Library not loaded: /System/Volumes/Data/builds/workspace/music-macos-free/build/medInria-build/lib/resource_libs/libmedWidgets.dylib\n Referenced from: /Applications/MUSICardio 2.app/Contents/PlugIns/libmedItkArithmeticOperationProcessPlugin.dylib\n Reason: tried: '/System/Volumes/Data/builds/workspace/music-macos-free/build/medInria-build/lib/resource_libs/libmedWidgets.dylib' (no such file), '/usr/local/lib/libmedWidgets.dylib' (no such file), '/usr/lib/libmedWidgets.dylib' (no such file))"

It could be linked to #1039 which have been removed from mac_packager.sh.in. I am trying to test on our jenkins macOS item, but it's not ideal.

For now, to compile (on zsh):

resourceLibsDir=@medInria_BINARY_DIR@/lib/resource_libs #resources did not exist 
injectDirs="$injectDirs -inject-dir=$resourceLibsDir"

and (changing the app name)

echo "##########################"
contentsDir=@medInria_BINARY_DIR@/bin/TmpInstall/MUSICardio.app/Contents
ls $contentsDir/PlugIns

echo "########################## 2 "
dylibNames=$(ls $contentsDir/PlugIns/*.dylib)
for lib in $dylibNames; do
    echo $lib
    libname=${lib##*/}
    installedName="@executable_path/../PlugIns/$libname"
    install_name_tool -id $installedName $contentsDir/PlugIns/$libname
done

# Resource libraries are sent as plugins to dtkDeploy (above) because they are
# not dependencies of the executable (dtkDeploy uses otool on the executable to
# find which libraires should be imported, so it will not find resource
# libraries). After the execution of dtkDeploy we move these libraries to the
# frameworks folder and adjust their install name.
resourceLibs=''
echo "########################## 3"
dylibResourceNames=$(ls $resourceLibsDir/*.dylib)
for lib in $dylibResourceNames; do
    echo $lib
    libname=${lib##*/}
    copiedLib=$contentsDir/Frameworks/$libname
    \mv $contentsDir/PlugIns/$libname $copiedLib
    installedName="@executable_path/../Frameworks/$libname"
    install_name_tool -id $installedName $copiedLib
    resourceLibs="$resourceLibs $libname"
done

# Because of the dtkDeploy bug with install names, we have to fix the
# dependencies of the resource libraries.
for lib1 in $resourceLibs; do
    deployedLib1=$contentsDir/Frameworks/$lib1
    installedName="@executable_path/../Frameworks/$lib1"
    for lib2 in $resourceLibs; do
        deployedLib2=$contentsDir/Frameworks/$lib2
        install_name_tool -change $1/$lib1 $installedName $deployedLib2
    done
done

But i've a crash on the macOS computer of a colleague which tried the dmg. I'll have a macOS soon to test, but it can take some time.

This needs to be solved for 3.3 release.

[mathildemerle]

@fcollot if you have an answer for that problem it could be great. I don't have a macOS machine yet, it's in preparation (i hope i'll have it this week), and i won't be here next week. And since it was your code, you could have a quicker answer maybe, for us to be able to do a release soon ?

[fcollot]

The two lines:

resourceLibsDir=@medInria_BINARY_DIR@/lib/resources
injectDirs="$injectDirs -inject-dir=$resourceLibsDir"

should have been removed in the previous PR.

[fcollot]

I tried with the removal of the above lines and the problem persists. mac_packager.sh.in is now the same as it was before the code I added so the issue is elsewhere.

[fcollot]

This issue was introduced with #1029. The new code did not take into account the RESOURCE option of the set_lib_install_rules function. As a consequence all libraries are treated as resource libs, and so removing support for those libs automatically causes all libs to be ignored.

[fcollot]

I have fixed this, and all legacy plugins are packaged and loaded, but the new plugins (listed in the error message at the top of this issue) are still not loaded. I do not know what the origin of that bug is, but it is not related to the resource library code.