for a simpler example of the changing-rpath mehod, purest_json also distributes shared libs on osx (recursively through the dependencies) https://github.com/residuum/PuRestJson of course that relies on using homebrew, which afaik only ships 1 arch in its binaries (and now they removed options like "--universal" for formulas too :-/)but modifying its dependencies.sh file could still work on another directory that you build universals into yourself. -seb ----------Message: 3 Date: Wed, 4 May 2022 02:37:32 +0200 From: Dan Wilcox danomatika@gmail.com To: Roman Haefeli reduzent@gmail.com Cc: pd-dev pd-dev@lists.iem.at Subject: Re: [PD-dev] building fluidsynth~ (was: building fluid~ on Linux) Message-ID: C5C66392-A7B9-4D3D-A0E7-D8E930DCBC2C@gmail.com Content-Type: text/plain; charset="us-ascii"
(fixing subject line I forgot in previous email)
I forgot to mention that my response was directed more for macOS and possibly Windows where asking people to use a package manager is a bit more of a stretch as opposed to Linux. In general, dependent libs are packaged with the program itself and sometimes dynamic linking can be problematic, ie. on macOS you often have to (re)set the rpath in a built lib. That dance in avoided by simply statically linking at the expense of binary size. I'm not saying it's the best solution, but it may be more maintainable and usable in the case of a dynamically-loaded Pd external.
OTOH I believe GEM provides dynamic libs along with the externals on macOS but this most probably requires fiddling with the rpath, basically overriding the search path for the lib to it's found in a different, non-system location.
For Windows, if I recall correctly, you generally just need to place the dlls next to whatever is using them.
As for mixing static and dynamic linking, I believe that's not a problem as long as the dynamic libs are found.
On May 4, 2022, at 12:06 AM, pd-dev-request@lists.iem.at wrote:
Message: 2 Date: Tue, 03 May 2022 23:53:26 +0200 From: Roman Haefeli <reduzent@gmail.com mailto:reduzent@gmail.com> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: Re: [PD-dev] Pd-dev Digest, Vol 204, Issue 11 Message-ID: <0ab1d4fbc2d4d0f609870c1b5f06178a0fdc6a23.camel@gmail.com mailto:0ab1d4fbc2d4d0f609870c1b5f06178a0fdc6a23.camel@gmail.com> Content-Type: text/plain; charset="utf-8"
On Tue, 2022-05-03 at 23:29 +0200, Dan Wilcox wrote:
My two cents: I have tried in the past to bundle dynamic libs generated/downloaded by homebrew into app distributions to run on other systems and *always* run into problems. It hs always been simpler to statically link, either to the home-brew lib or by building the lib(s) myself using a script or makefile. For longer term projects, I generally prefer to automate building the lib statically then linking it directly into the program.
THanks for your insight.
Please forgive the noob question, but do I have static builds of all the dependencies available for that to work? And if I don't, do I have to compile the dependencies and make sure they're built statically (which isn't always obvious to me with the various build systems).
Roman
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 5/4/22 03:47, Sebastian Shader via Pd-dev wrote:
for a simpler example of the changing-rpath mehod, purest_json also distributes shared libs on osx (recursively through the dependencies) https://github.com/residuum/PuRestJson
probably simpler. but from what i've seen so far, this is just another copy (of with some minor modifications) of the original embed-OSX-libraries script that hans-christof wrote two decades ago.
my script (that roman mentioned) [1] for the iem-ci (where it is stress tested wih all those iem externals, including beasts like Gem), is also based on that original embed-OSX-libraries script, but has seen a number of improvements over the last 20 years, like being independent of homebrew (think macports; or your own personal package manager) or having a consistent interface across various platforms (i have multiple scripts [2] for windows/macOS/linux, but they all share the same interface).
but modifying its dependencies.sh file could still work on another directory that you build universals into yourself.
yes. or just use a script that already has those modifications :-)
of course you can use/hack/... whatever script you find out there.
the reason why i promote mine is, that i want it to become better and better and fix all the bugs that people on diverse environments come across (with a strong focus on making it work in automated environments). so that when people come and ask "how do i ship all those external libraries with my Pd-external" there is a single reference implementation, rather than handful scripts all tailored to specific needs and with their own idiosyncratic (or just inherited) bugs.
gfmasdr IOhannes
[1] https://git.iem.at/pd/iem-ci/-/blob/main/localdeps/localdeps.macos.sh [2] https://git.iem.at/pd/iem-ci/-/tree/main/localdeps