> On Jun 15, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 1
> Date: Tue, 14 Jun 2022 14:23:16 +0200
> From: reduzent(a)gmail.com <mailto:reduzent@gmail.com>
> To: pd-dev(a)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(a)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/>
In my opinion (and experience), it's easier to make a fat lib. This is how most things are distributed on the platform moving forward. Technically, providing the arches as separate files should be possible but the question comes down to naming and/or separating the distribution in such a way that the system lib loading can find them correctly. With a fat lib build, you don't have to worry about it. I have honestly never bothered to figure out the separate arch, separate lib approach beyond major differences of OS versions ie. macOS 10.6 - 10.9, macOS 10.10+, etc.
> On Jun 15, 2022, at 1:32 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 2
> Date: Wed, 15 Jun 2022 13:32:09 +0200
> From: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>>
> To: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>>
> Subject: Re: [PD-dev] Compiling fat external binaries for Mac OS X
> Message-ID: <ce868065d84420fd1d5115a34b0f433ba0a82d70.camel(a)gmail.com <mailto:ce868065d84420fd1d5115a34b0f433ba0a82d70.camel@gmail.com>>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2022-06-15 at 12:53 +0200, Dan Wilcox wrote:
>>
>>> On Jun 15, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at <mailto: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(a)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.
>>
>
> 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
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
You can simply pass in the arches you want using the "arch" makefile variable:
make arch="x86_64 arm64"
For example:
danomatika@danomatika helloworld % make arch="x86_64 arm64"
++++ info: using Makefile.pdlibbuilder version 0.6.0
++++ info: using Pd API /Applications/Pd-0.52-2.app/Contents/Resources/src/m_pd.h
++++ info: making target all in lib helloworld
++++ info: making helloworld.o in lib helloworld
cc -DPD -I "/Applications/Pd-0.52-2.app/Contents/Resources/src" -DUNIX -DMACOSX -I /sw/include -Wall -Wextra -Wshadow -Winline -Wstrict-aliasing -O3 -ffast-math -funroll-loops -fomit-frame-pointer -arch x86_64 -arch arm64 -mmacosx-version-min=10.6 -o helloworld.o -c helloworld.c
++++ info: linking objects in helloworld.pd_darwin for lib helloworld
cc -undefined suppress -flat_namespace -bundle -arch x86_64 -arch arm64 -mmacosx-version-min=10.6 -o helloworld.pd_darwin helloworld.o -lc
++++info: target all in lib helloworld completed
danomatika@danomatika helloworld % file helloworld.pd_darwin
helloworld.pd_darwin: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit bundle x86_64] [arm64:Mach-O 64-bit bundle arm64]
helloworld.pd_darwin (for architecture x86_64): Mach-O 64-bit bundle x86_64
helloworld.pd_darwin (for architecture arm64): Mach-O 64-bit bundle arm64
As to which versions of macOS (that's the official name for some years now) to build on, I believe you can still build the i386 arch with Xcode on macOS 10.15, so judging from the following it may be Xcode 11 or 12: https://xcodereleases.com <https://xcodereleases.com/>. I think Alex Porres is using this set up, so maybe he can chime in with his combo of OS and Xcode. The irony is that you can't run the 32 bit arch on 10.15, but at least you can build for it. Xcode on macOS 11 (version after 10.15) only allows for building x64_64 and arm64.
I did add an "automatic" fat lib checker which determines which arch are available for the Xcode version but it's sitting in a PR right now. IN the end, I think I agree with IOhannes that it's maybe better to document and ask the user to set the required arch manually. It certainly keeps things simpler to maintain.
The readme should probably be updated with this info as these questions keep resurfacing.
> On Jun 8, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 1
> Date: Wed, 8 Jun 2022 01:18:39 +0200
> From: Thomas Mayer <thomas(a)residuum.org <mailto:thomas@residuum.org>>
> To: pd-dev <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>>
> Subject: [PD-dev] Compiling fat external binaries for Mac OS X
> Message-ID: <7fd6ada6-3f36-316b-9000-30e0cd64118a(a)residuum.org <mailto:7fd6ada6-3f36-316b-9000-30e0cd64118a@residuum.org>>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi,
>
> I am currently working on the last steps for releasing a new version of
> PuREST JSON.
>
> My main concern is now building fat binaries for Mac OS X.
>
> When I look at the list at the different versions for 0.52-2 at
> https://puredata.info/downloads/pure-data <https://puredata.info/downloads/pure-data> there is a version labeled "M1
> and Intel/64bit". I guess, I should link to it.
>
> Is there any environment variable I have to set for building building?
>
> I am using the current master version of pd-lib-builder, and I do not
> see any reference to M1 in the block there:
> https://github.com/pure-data/pd-lib-builder/blob/e6cff665a3a30a967c72c382c6… <https://github.com/pure-data/pd-lib-builder/blob/e6cff665a3a30a967c72c382c6…>
>
> Also, what should be in the filename for deken zips?
>
> Any other version of Mac OS X that I should compile the external as
> well, since there are downloads for 32 and 64 bit Intel as well?
> Especially, because the 64 bit version is labeled as OS X 10.7 - 10.9.
>
> The question about filename of deken zips applies to these as well.
>
> Thanks,
> Thomas
> --
> "As long as people kept worrying that the machines were taking over,
> they wouldn't notice what was really happening. Which was that the
> programmers were taking over." (Robert Anton Wilson - The Homing Pidgeons)
> http://www.residuum.org/ <http://www.residuum.org/>
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
Hi,
I am currently working on the last steps for releasing a new version of
PuREST JSON.
My main concern is now building fat binaries for Mac OS X.
When I look at the list at the different versions for 0.52-2 at
https://puredata.info/downloads/pure-data there is a version labeled "M1
and Intel/64bit". I guess, I should link to it.
Is there any environment variable I have to set for building building?
I am using the current master version of pd-lib-builder, and I do not
see any reference to M1 in the block there:
https://github.com/pure-data/pd-lib-builder/blob/e6cff665a3a30a967c72c382c6…
Also, what should be in the filename for deken zips?
Any other version of Mac OS X that I should compile the external as
well, since there are downloads for 32 and 64 bit Intel as well?
Especially, because the 64 bit version is labeled as OS X 10.7 - 10.9.
The question about filename of deken zips applies to these as well.
Thanks,
Thomas
--
"As long as people kept worrying that the machines were taking over,
they wouldn't notice what was really happening. Which was that the
programmers were taking over." (Robert Anton Wilson - The Homing Pidgeons)
http://www.residuum.org/
Hey all
I created a "Pure Data" team for providing up-to-date builds for
Ubuntu:
https://launchpad.net/~pure-data
Currently, there is one 'pure-data' PPA for hosting 'puredata'
packages. Yet, IOhannes and me are members. If anyone would like to
join, please let me know.
If there is ever a need, we could also create a 'pd-externals' PPA for
hosting up-to-date external packages. However, my impression is things
aren't evolving quickly these days and what is already in Debian (and
Ubuntu) seems to work fine and up-to-date (mainly thanks to IOhannes).
For new packages, the effort is better spent in bringing them into
Debian.
I updated the respective FAQ entry to reflect the new home of the pure-
data PPA:
https://puredata.info/docs/faq/debian
Roman
Hi, after more than a year, I'm finally going to release my fluidsynth~
object as part of ELSE. There were lots of discussion on this list about
this. One big issue was how to ship the external along with the library
dependencies. There are scripts taken from https://git.iem.at/pd/iem-ci to
copy the libs to the same folder as the external. It seems we got to a
point of being able to build it for mac and windows. This last thread (from
where I'm now opening a new one) was about building it for Linux.
After so long I just tried to build it on my new system and my new
challenge would be to see if it'd work for apple silicon macs. First I just
tried building for mac intel using my new setup, a monterey machine with
the latest XCode. I started by installing fluidsynth, now at a much more
recent version 2.2.7, I then built the external and it worked fine in the
system I built this on. I tried the localdeps.macos.sh script and it did
copy all the libs to the same folder as the external, so I zipped it and
uploaded to https://github.com/porres/pd-fluidsynth/releases/tag/0.0.0-test so
I could test on another machine without fluidsynth and all... guess what?
it didn't work!
By the way, someone built it for windows and I was able to test that it
works on a virtual windows machine, so I don't know what could be wrong
with my setup... See
https://github.com/charlesneimog/pd-fluidsynth/releases/tag/v0.0.1 note
that there's also a mac version there, but it doesn't work either and seems
to be worse than my attempt as there a no libs copied. You cal also test
the linux version in there.
Hope someone can give me a hint why my new attempt didn't work for mac, I
don't know what could be different other than having a new system a new
version of the OS, of XCode and fluidsynth.
cheers
Em qui., 14 de jan. de 2021 Ã s 18:16, Roman Haefeli <reduzent(a)gmail.com>
escreveu:
> On Thu, 2021-01-14 at 16:52 +0100, IOhannes m zmölnig wrote:
> > On 1/14/21 10:42 AM, Roman Haefeli wrote:
> > > See PR:
> > > https://github.com/porres/pd-fluidsynth/pull/5
> > >
> >
> > given that i consider myself upstream of the original
> > "localdeps.*.sh"
> > scripts and those scripts are located under
> > https://git.iem.at/pd/iem-ci
> > where they are used by a number of (our, that is: the iem's)
> > libraries,
> > i would highly welcome it if you could submit a PR to that central
> > location rather than a single one of the consumers of those scripts.
>
> Sure. I wasn't even aware of the origin of those files.
>
> Re PR/MR:
> While logged in as reduzent, I see only comport listed as repos I can
> create MRs for. I don't seem to have privileges for forking on
> git.iem.at nor for creating MRs for the iem-ci repo. Tell me if I'm
> overseeing something.
>
> I created a fork on:
> https://gitlab.zhdk.ch/rhaefeli/iem-ci
>
> You'll find the script addition in the linuxdep branch.
>
> Roman
> _______________________________________________
> Pd-dev mailing list
> Pd-dev(a)lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
Should we consider having a copy of the old or your new script in a canonical repo such as with pd-lib-builder? Or it's own GH repo? Something similar could be a makefile or script to help automate the whole macOS code signing process as well.
> On May 4, 2022, at 8:32 AM, pd-dev-request(a)lists.iem.at wrote:
>
> 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 <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).
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
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(a)gmail.com>
To: Roman Haefeli <reduzent(a)gmail.com>
Cc: pd-dev <pd-dev(a)lists.iem.at>
Subject: Re: [PD-dev] building fluidsynth~ (was: building fluid~ on
   Linux)
Message-ID: <C5C66392-A7B9-4D3D-A0E7-D8E930DCBC2C(a)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(a)lists.iem.at wrote:
>
> Message: 2
> Date: Tue, 03 May 2022 23:53:26 +0200
> From: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>>
> To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] Pd-dev Digest, Vol 204, Issue 11
> Message-ID: <0ab1d4fbc2d4d0f609870c1b5f06178a0fdc6a23.camel(a)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/>
(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(a)lists.iem.at wrote:
>
> Message: 2
> Date: Tue, 03 May 2022 23:53:26 +0200
> From: Roman Haefeli <reduzent(a)gmail.com <mailto:reduzent@gmail.com>>
> To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>
> Subject: Re: [PD-dev] Pd-dev Digest, Vol 204, Issue 11
> Message-ID: <0ab1d4fbc2d4d0f609870c1b5f06178a0fdc6a23.camel(a)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/>