Hi Ryan, This is very helpful! Thanks for taking the time to write this.
I will continue to look into this and hope to get some clarity about a working solution. Thanks, again for your help. -Manav > On Jul 20, 2018, at 2:01 PM, Ryan Schmidt <[email protected]> wrote: > > > > On Jul 20, 2018, at 13:24, Manav Bhatia wrote: > >> No GUI. My app is a terminal application with plenty of dependencies. My >> users are at places and on systems without root access. >> >> I am not sure what the best approach is here, but I am looking at various >> options where I can distribute precompiled binaries. >> >> Dylibbundler sounds interesting but I have no experience to try to judge its >> limitations. >> >> I am also looking at CPack (from cmake), which seems to have some promise as >> it is cross-platform compatible, so I can use the same cmake configuration >> script to create bundles on Mac and Linux. >> >> I need these to work in non-standard, non-root locations. >> >> This should not be so difficult. > > It's important to realize that macOS and Linux use different executable > formats. Mac uses Mach-O, and Linux uses ELF, and they are not the same, and > they were designed with different goals in mind and different capabilities. > So a solution that works on Linux won't necessarily work on macOS, and vice > versa. > > On macOS, a library contains the absolute path to where it is installed. The > is called its "install_name" and it is set at build time. If the library is > later moved on disk, install_name_tool must be used to update the library's > install_name to its new location. Similarly, any program (or other library) > that links with that library does so by its install_name. If the library is > moved, install_name_tool must be used to update the reference to the library > in the program (or other library). > > It is also possible to set install_names that are relative to one of several > different places, instead of absolute. For example, you could set the > install_name to be relative to the path of the program that loaded it. This > is not appropriate for libraries that are meant to be used by many different > programs that might be in many different locations -- this is the situation > we have in MacPorts, which is why MacPorts does not attempt to use relative > paths for libraries. But if you are creating a standalone package for one > program (or a few related programs), such that you can dictate the relative > paths between all the programs and libraries, and you want that standalone > package to be relocatable, then you could use relative paths in the > install_names. > > dylibbundler automates the process of running the necessary install_name_tool > commands to change absolute install_names to relative ones. However I believe > it also assumes that what it is producing is a standard macOS application > bundle. If you're not producing an app but instead just a directory of > programs and libraries, you will have to see if you can use dylibbundler's > various flags to produce the desired file layout. > > For the purposes of dylibbundler, it does not matter if the programs and > libraries that it is changing came from our build server's binaries or were > compiled by you on your computer. However, for your project, it may matter. > For example, you may wish to distribute something that runs on 10.9 or later, > but you are running on 10.13. The binaries compiled on our build server for > 10.13 are intended for use on 10.13 only. If you want to compile something on > 10.13 that can still run on 10.9, you have to set MACOSX_DEPLOYMENT_TARGET to > 10.9. MacPorts allows you to specify this in macports.conf, but for it to > take effect, you have to compile ports yourself; binaries you get from us > won't respect that setting. Alternately, you could prepare your package on a > system running 10.9. You'll be able to use MacPorts 10.9 binaries, and they > should work on later systems, though of course they won't be able to use any > capabilities introduced in later macOS versions. > > As Craig said, making the programs and libraries use relative install_names > may not be all you need to do. The absolute install path might also be baked > into the programs in other ways. You can grep all of the files you plan to > distribute and see if they contain the old install path. If so, you'll have > to investigate what needs to be done to fix it. Unfortunately, there is not a > one-size-fits-all solution for this. > > \r > >
