Safest way is to statically link everything into the external itself. Yes, this makes it huge but that's the *safest* method.
Next method is to bundle the libs *with* the external *and* modify the externals' lib search path (RPATH) to check a local location first so the system loader will find your dylibs. Both methods are what macOS .app bundles do: either statically link *or* ship the dylibs inside the bundle. That being said, if the libs require internal APIs which change between macOS versions, then you may have to consider separate builds. However, despite all of the FUD mostly from people who don't use the platform often, Apple clearly deprecates APIs long in advance. The only libs that are generally *safe* to link to across macOS versions are libraries included with the system such as libxml2... but I would say that is about the only C system lib that I have directly linked to in *any* software I have written for macOS, that is beyond the internal Obj-C / Swift frameworks. I generally recommend *against* asking users to install libs via Homebrew. macOS is not Linux and Homebrew is not apt. Homebrew is heavily oriented towards developers and lib versions change pretty dynamically. There is no guarantee the lib you linked again on your build machine will match that of whatever version of macOS & Homebrew a user has. I have tried this approach with macOS .app bundles at work and only run into problems. For Homebrew to be a viable option, the best way is to require users to install the libs via Homebrew and build the external themselves. This is basically what HB is designed for, however, I assume this is what you are trying to avoid. That same goes for trying to pull a dylib from Homebrew and bundling it within your .app. I only ran into problems with as well and have generally written scripts or Makefiles to build all of my dependencies manually for distribution. Linking to a static version *may* work, but you still may run into issues if you require a *specific* version of the lib. > On Jun 16, 2022, at 12:00 PM, [email protected] wrote: > > Would it be better for externals shipping with local dependencies to > provide them as fat binaries? For externals using localdeps I use > separate non-fat files, because they both link to different hard-coded > paths. I wouldn't how to do it differently. > > Is there a best way for shipping externals with local dependencies? If > yes, which is it? > > Roman -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
