On Jun 15, 2022, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Message: 1 Date: Tue, 14 Jun 2022 14:23:16 +0200 From: reduzent@gmail.com mailto:reduzent@gmail.com To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: Re: [PD-dev] Compiling fat external binaries for Mac OS X Message-ID: <3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.camel@gmail.com mailto:3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.camel@gmail.com> Content-Type: text/plain; charset="UTF-8"
On Wed, 2022-06-08 at 20:04 +0200, Dan Wilcox wrote:
You can simply pass in the arches you want using the "arch" makefile variable:
make arch="x86_64 arm64"
That's cool to know. In the case of purest_json, I believe it ships with other dependencies (libjson?) and if those come from homebrew, they're probably not fat. Is my assumption correct, that a fat binary would have to link to fat binary?
I don't believe so. I think (not 100%) the system lib loading mechanism just needs to find the lib *and* have the right arch. I don't believe it matters if the lib is fat or not.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Wed, 2022-06-15 at 12:53 +0200, Dan Wilcox wrote:
On Jun 15, 2022, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Message: 1 Date: Tue, 14 Jun 2022 14:23:16 +0200 From: reduzent@gmail.com To: pd-dev@lists.iem.at Subject: Re: [PD-dev] Compiling fat external binaries for Mac OS X Message-ID: 3646dbc2fcbfdf0a16d8feb20aa7bb11a6f5db58.camel@gmail.com Content-Type: text/plain; charset="UTF-8"
On Wed, 2022-06-08 at 20:04 +0200, Dan Wilcox wrote:
You can simply pass in the arches you want using the "arch" makefile variable:
make arch="x86_64 arm64"
That's cool to know. In the case of purest_json, I believe it ships with other dependencies (libjson?) and if those come from homebrew, they're probably not fat. Is my assumption correct, that a fat binary would have to link to fat binary?
I don't believe so. I think (not 100%) the system lib loading mechanism just needs to find the lib *and* have the right arch. I don't believe it matters if the lib is fat or not.
Thanks for the clarification. The interesting question (to me at least) is: If I want to support both archs, does the linked library need to be fat, or can I link to two separate files per dependency? If I can't link to different files for different archs, this means there is no other way for maintaining support of both archs than to link to a fat library.
Roman
On 6/15/22 12:53, Dan Wilcox wrote:
make arch="x86_64 arm64"
That's cool to know. In the case of purest_json, I believe it ships with other dependencies (libjson?) and if those come from homebrew, they're probably not fat. Is my assumption correct, that a fat binary would have to link to fat binary?
I don't believe so. I think (not 100%) the system lib loading mechanism just needs to find the lib *and* have the right arch. I don't believe it matters if the lib is fat or not.
that is my experience as well. you can have a fat (say: amd64, arm64) external that links against "libfoo". if on the target system, there's only a non-fat (say: "amd64") version of "libfoo", then you will be able to use the external on amd64 (either natively or via Rosetta), but not as an "arm64" binary. if you then install "libfoo" also for arm64 (e.g. via homebrew), you can use the external on arm64 as well.
this is basically what's happening for the experimental Gem binaries right now: - the Gem.pd_linux is built as a fat amd64/arm64 binary (and all the backend plugins and helper externals as well) - the build machine is an amd64 host, so "homebrew" only installs amd64 binaries on that machine - Gem tries to bundle up the dependencies, but since they are only for amd64, whatever the build-scripts embeds is for amd64 only as well - thus downloading the CI-built Gem will work find on amd64 hosts or with Rosetta - if you want to run Gem (with all the backends) natively on your M1, you need to manually "brew install" the missing libraries. the Gem-binaries will pick them up and :tada:
gfmasdr IOhannes
On Wed, 2022-06-15 at 13:59 +0200, IOhannes m zmoelnig wrote:
On 6/15/22 12:53, Dan Wilcox wrote:
make arch="x86_64 arm64"
That's cool to know. In the case of purest_json, I believe it ships with other dependencies (libjson?) and if those come from homebrew, they're probably not fat. Is my assumption correct, that a fat binary would have to link to fat binary?
I don't believe so. I think (not 100%) the system lib loading mechanism just needs to find the lib *and* have the right arch. I don't believe it matters if the lib is fat or not.
Ah, I see.
that is my experience as well. you can have a fat (say: amd64, arm64) external that links against "libfoo". if on the target system, there's only a non-fat (say: "amd64") version of "libfoo", then you will be able to use the external on amd64 (either natively or via Rosetta), but not as an "arm64" binary. if you then install "libfoo" also for arm64 (e.g. via homebrew), you can use the external on arm64 as well.
So you're saying: Because it searches pre-configured paths for finding libraries, it'll find the right arch if it is available. Thus, you don't need to link to fat libraries for full fat support, as long as both arch's libraries are installed.
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 -
IOhannes m zmoelnig -
Roman Haefeli