I'm trying to distribute a .app that has dependencies on some of the gcc libraries such as libgcc_s.2.dylib and libstdc++.6.dylib, and I need some advice in terms of dealing with code signing.
Since I'll be distributing this, I'm copying all the gcc libraries the application depends on inside the .app, which means that the linking path will no longer be correct. To fix this, I use install_name_tool -change to update the linking path to the correct one, something like this:
install_name_tool -change /opt/homebrew/lib/gcc/libgcc_s.2.dylib @loader_path/libgcc_s.2.dylib libstdc++.6.dylib
Since this is a 3rd party library which was already signed, doing this outputs the following warning :
install_name_tool: warning: changes being made to the file will invalidate the code signature in: libstdc++.6.dylib
Which effectively breaks my application since the code signature is no longer valid for the 3rd party libraries. Now this leaves me with the question: how do I get around this? Can I codesign them myself even if I'm not the developer of these 3rd party libraries? If so, how do I do that? I wasn't able to find any similar problems in my research, yet it seems like a basic problem for distributing mac applications.
How exactly do you deal with codesigned 3rd party libraries when you need to distribute your app that depends on them, seeing as you need to configure these to link correctly after moving them?