0

This is my first time creating an installer for an application and I need some advice.

This application depends on A.dylib, and A.dylib depends on two other libraries: libstdc++.6.dylib and libgomp.1.dylib which all come from the gcc folder. When I do otool -L on A.dylib, this is what I get :

A.dylib (compatibility version 0.0.0, current version 0.0.0)
/opt/homebrew/opt/gcc/lib/gcc/10/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.28.0)
/opt/homebrew/opt/gcc/lib/gcc/10/libgomp.1.dylib (compatibility version 2.0.0, current version 2.0.0)

Which means that if these two libraries aren't in there, the application won't launch at all. So my problem is with the installer, am I supposed to install libstdc++.6.dylib and libgomp.1.dylib in /opt/homebrew/opt/gcc/lib/gcc/10/ for the user? Even if they don't have a gcc installed there, or at all?

Another option is to install the libraries under say /Library/Application Support/, but then this would mean that the path A.dylib is linked to won't be correct anymore. How do I change the linking path automatically after I install those libraries? What is the best way to go beyond this?

  • Does this answer your question? [dyld: Library not loaded: ..... How to correctly tell GCC Compiler where to find another static library?](https://stackoverflow.com/questions/66268814/dyld-library-not-loaded-how-to-correctly-tell-gcc-compiler-where-to-find) – Siguza Mar 04 '21 at 02:12
  • Neither of your options, although they may work, are what you want. The best way is to bundle. – Richard Barber Mar 04 '21 at 06:30
  • @RichardBarber could you go a bit more in detail what do you mean by bundling? – Luis Angel Urena Lopez Mar 04 '21 at 16:55
  • @Siguza `install_name_tool` is a great tool for this, thank you. Unfortunately, I run into a problem when I use it on 3rd party libraries (from gcc folder), it invalides the code signature. I saw at the end of your answer you mentioned it briefly, which seemed interesting. Do you know any site/documentation that goes a bit more on depth on how to use codesign for this specific situation? – Luis Angel Urena Lopez Mar 04 '21 at 16:58
  • To note that this is my first time working on Mac and my first time seeing the concept of codesigning, so I'm a complete beginner for this scenario. – Luis Angel Urena Lopez Mar 04 '21 at 16:59
  • @LuisAngelUrenaLopez depends on what kind of signature you need. In general, `codesign -f` can replace an existing signature. For an ad-hoc signature, `codesign -f -s - [file]` should do the trick... otherwise see `man codesign`. But if you need to keep the signing identity of a 3rd-party, then you simply cannot modify the dylib. That's what the code signature ensures. – Siguza Mar 04 '21 at 17:01
  • @Siguza I understand that's what the code signature ensures, makes total sense. This means I need to keep the 3rd party libraries untouched, which raises a problem for me. Since I'm moving all the libraries inside the .app, that means the path it's linked to will be wrong once they're moved. Since I can't modify that path, do you recommend me to install these libraries on the user's computer exactly on the path the dependencies are pointing to? Or is there a cleaner way to do this without invalidating the code signature? – Luis Angel Urena Lopez Mar 04 '21 at 17:21
  • https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html The application bundle structure. – Richard Barber Mar 05 '21 at 00:02

0 Answers0