Pd-dev May 2022

pd-dev@lists.iem.at

5 participants
13 discussions

Pure Data team on launchpad.net
by Roman Haefeli 13 May '22

13 May '22

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

1 0

building fluidsynth~ (was: building fluid~ on Linux)
by Alexandre Torres Porres 04 May '22

04 May '22

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 >

4 23

Re: [PD-dev] embedding macOS libraries (was Re: building fluidsynth~)
by Dan Wilcox 04 May '22

04 May '22

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/>

1 0

Re: [PD-dev] codesigning externals (was Re: building fluidsynth~)
by Dan Wilcox 04 May '22

04 May '22

This is correct. I added it to the Pd app bundle entitlements to get rid of the error dialog for (older) externals on macOS 10.15, I believe: https://github.com/pure-data/pure-data/blob/master/mac/stuff/pd.entitlements <https://github.com/pure-data/pure-data/blob/master/mac/stuff/pd.entitlements> https://eclecticlight.co/2021/01/07/notarization-the-hardened-runtime/ <https://eclecticlight.co/2021/01/07/notarization-the-hardened-runtime/> If you start signing dynamic libs, I think you also need to set the min deployment target to 10.9 or above, at least for apps with a "hardened run-time" but I'm not sure if Pd does since we are (re)using the Wish app from the Tk build process. (I *think* it is as it is enabled during the code sign steps which apply the entitlements?.) The security settings like these are much more obvious when making a more "native app" via Xcode but less so when building on the command line. In any case, I did a quick search and found the following: https://developer.apple.com/forums/thread/130065 <https://developer.apple.com/forums/thread/130065> https://developer.apple.com/documentation/security/hardened_runtime <https://developer.apple.com/documentation/security/hardened_runtime> etc... (Sorry for not being the authority on this. I honestly try to write scripts for this so I can flush my memory every time I deal with code signing.) > On May 4, 2022, at 8:32 AM, pd-dev-request(a)lists.iem.at wrote: > > i guess that while Pd has the permission to load *unsigned* externals, > macOS still refuses to load *signed* externals with an invalid signature. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] building fluidsynth~ (was: building fluid~ on Linux)
by Sebastian Shader 04 May '22

04 May '22

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/>

2 1

Re: [PD-dev] building fluidsynth~ (was: building fluid~ on Linux)
by Dan Wilcox 04 May '22

04 May '22

(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/>

1 0

Re: [PD-dev] Pd-dev Digest, Vol 204, Issue 11
by Dan Wilcox 03 May '22

03 May '22

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. > On May 3, 2022, at 8:57 PM, pd-dev-request(a)lists.iem.at wrote: > >>> I often find things are a bit easier on Linux, but that's what I >>> got >>> accustomed to. In the case of the fluidsynth~ external, using the >>> dynamic libraries from my distro (Ubuntu 22.04) doesn't seem >>> practical, >>> as libfluidsynth.so.3 links against virtually half the system. >>> After >>> executing the localdep script, I end up with 53 *.so files. Most of >>> them aren't actually used when libfluidsynth is used for the pd >>> external. Creating a more stripped down build of libfluidsynth >>> probably >>> would make sense here. > >> Cool, but how? :)? > > By building fluidsynth from source with the minimal set of configure > flags required for the pd external. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Re: [PD-dev] [PD] how to compile externals for apple silicon?
by Dan Wilcox 01 May '22

01 May '22

Honestly, I don't know. I've not looked into specific versions of which Xcode can compile what. I basically just follow the normal upgrade cycle of keeping Xcode up to date with whatever macOS version I currently have. I don't care to spend much more headspace on it than that! At some point, I couldn't build for i386 (I think some version of Xcode 10) so I removed building for x86_64. The same happened when I upgraded to some version of Xcode 12, I think, which included the SDK which includes compiler support for arm64. I assumed I couldn't build i386 some time when I was on macOS 10.15 but I didn't write it down. If you want to spend the time for an answer, probably read through the Xcode release notes: https://developer.apple.com/documentation/xcode-release-notes <https://developer.apple.com/documentation/xcode-release-notes>. If you want to download and try different Xcode version, there is a handy site to the downloads provided by the Apple Developer portal: https://xcodereleases.com <https://xcodereleases.com/> You will need a developer account to access them. > On May 1, 2022, at 5:30 PM, Alexandre Torres Porres <porres(a)gmail.com> wrote: > > Em dom., 1 de mai. de 2022 às 04:42, Dan Wilcox <danomatika(a)gmail.com <mailto:danomatika@gmail.com>> escreveu: > You cannot build for i386. Support for that arch was famously removed in macOS 10.15 and those versions of Xcode which use its SDK, probably version 10 or so. Modern fat libs arm64 and x86_64. > > Damn, double checked and tested. Using XCode 12.4 on Catalina, I was able to compile else with a fat binary for both 32/64 bits, see --> https://github.com/porres/pd-else/issues/1241#issuecomment-1114263525 <https://github.com/porres/pd-else/issues/1241#issuecomment-1114263525> > > Back on Mojave, I downloaded 0.52-2 32 bits and tested the externals, it worked! > > I can see it shouldn't, it really makes sense it should build or work, I should have known better and expected a failure and be amazed when it first compiled because it doesn't make sense, but it's happening. > > Also, I can't build for arm64... > > Anyone can help me solve the mistery? > > screenshot to try to prove i'm not crazy > > <166152846-b962d8e0-6fc7-461c-a1f0-e8e04c0d9682.png> > > > enohp ym morf tnes > ----------- > Dan Wilcox > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/> > > >> On May 1, 2022, at 2:51 AM, Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> wrote: >> >> >> >> >> >> Em qui., 10 de mar. de 2022 às 19:57, Dan Wilcox <danomatika(a)gmail.com <mailto:danomatika@gmail.com>> escreveu: >> I have a fork of pd-lib-builder which supports arm64 & universal builds on macOS. The PR has been sitting for some time but we have been using it successfully for a few projects for some time now: >> >> https://github.com/pure-data/pd-lib-builder/pull/69 <https://github.com/pure-data/pd-lib-builder/pull/69> >> >> To build for arm64, you need a new enough Xcode (12.2 I believe) and that's it. You can cross-compile on an x86_64 machine for arm64 and vice-versa. >> >> So, I now have a partition with Catalina (10.15.7) and Xcode 12.4, which is the last version catalina accepts. >> >> According to https://developer.apple.com/pt/support/xcode/ <https://developer.apple.com/pt/support/xcode/> I believe 12.1 could have been possible already. 12.5 needs Big Sur. Here's a table from the link >> >> Versão do Xcode Sistema operacional mínimo necessário SDK Arquitetura Destinos de implantação Simulador Swift >> >> Xcode 12.4 macOS Catalina 10.15.4 (Mac com processador Intel) >> >> macOS Big Sur 11 >> (Mac com Apple Silicon) iOS 14.4 >> macOS 11.1 >> tvOS 14.3 >> watchOS 7.2 >> DriverKit 20.2 x86_64 >> armv7 >> armv7s >> armv7k >> arm64 >> arm64e >> arm64_32 iOS 9-14.4 >> iPadOS 13-14.4 >> macOS 10.9-11.1 >> tvOS 9-14.3 >> watchOS 2-7.2 >> DriverKit 19-20.2 >> >> It says it can build for 'arm64' alright, but I tried creating a fat binary for both intel and M1 as I was doing in my monterey partition and didn't succeed. I'm using pd-lib-builder, verdsion 6.0, so I did: >> >> make install objectsdir=../ arch="i386 x86_64" extension=d_fat and that works just fine >> >> but... >> >> make install objectsdir=../ arch="arm64 x86_64" extension=d_fat fails miserably, this is what I get >> >> >> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/cdefs.h:807:2: error: Unsupported architecture >> #error Unsupported architecture >> >> What should I do? >> >> My attempt here is to be able to build a binary for fluidsynth~ that works for a wide range of OSes >> >> thanks >> cheers >> >> >>> On Mar 10, 2022, at 11:30 PM, pd-dev-request(a)lists.iem.at <mailto:pd-dev-request@lists.iem.at> wrote: >>> >>> Message: 2 >>> Date: Thu, 10 Mar 2022 17:57:23 -0300 >>> From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> >>> To: Sebastian Shader <sebfumaster(a)aol.com <mailto:sebfumaster@aol.com>> >>> Cc: "pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>" <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> >>> Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon? >>> Message-ID: >>> <CAEAsFmiUpgiieWwpvM11eyY6kE6bdGiWFqFa8pbvPBjtuaoc4w(a)mail.gmail.com <mailto:CAEAsFmiUpgiieWwpvM11eyY6kE6bdGiWFqFa8pbvPBjtuaoc4w@mail.gmail.com>> >>> Content-Type: text/plain; charset="utf-8" >>> >>> I guess I can install catalina on a partition, but I was hoping to use >>> pdlibbuilder in an easy way, is it possible? >> >> -------- >> Dan Wilcox >> @danomatika <http://twitter.com/danomatika> >> danomatika.com <http://danomatika.com/> >> robotcowboy.com <http://robotcowboy.com/> >> >> >> -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 3

Re: [PD-dev] [PD] how to compile externals for apple silicon?
by Dan Wilcox 01 May '22

01 May '22

By "modern" I was referring to the architectures, not the lib bundling mechanism. I know I've mentioned it before and you bring it up again: it's probably possible to create a single fat lib with ppc, i386, x86_64, and arm64. This is, however, at best an academic exercise. > On May 1, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 1 > Date: Sun, 1 May 2022 10:52:17 +0200 > From: IOhannes m zm?lnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > To: pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at> > Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon? > Message-ID: <2a870fec-b81f-75d0-81e3-5a59462e2ebc(a)iem.at <mailto:2a870fec-b81f-75d0-81e3-5a59462e2ebc@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > On 5/1/22 09:42, Dan Wilcox wrote >> You cannot build for i386. Support for that arch was famously removed in macOS 10.15 and those versions of Xcode which use its SDK, probably version 10 or so. Modern fat libs arm64 and x86_64. > > just to add a bit of confusion... > > technically, i think there's no difference between a "modern" and a > "legacy" fat lib: it's a file format that can contain multiple > architectures. > there's absolutely nothing keeping you from having a fat binary that > contains arm64, x86_64, i386 and ppc. > > the only obstacle is, that there is no compiler that can create binaries > for all of these architectures. > but you can create the binaries on multiple systems (different macOS/OSX > versions; different Xcode installations) and then use 'lipo' to merge > the different single-arch binaries into a single fat one. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD-dev] [PD] how to compile externals for apple silicon?
by Dan Wilcox 01 May '22

01 May '22

I have a fork of pd-lib-builder which supports arm64 & universal builds on macOS. The PR has been sitting for some time but we have been using it successfully for a few projects for some time now: https://github.com/pure-data/pd-lib-builder/pull/69 <https://github.com/pure-data/pd-lib-builder/pull/69> To build for arm64, you need a new enough Xcode (12.2 I believe) and that's it. You can cross-compile on an x86_64 machine for arm64 and vice-versa. > On Mar 10, 2022, at 11:30 PM, pd-dev-request(a)lists.iem.at wrote: > > Message: 2 > Date: Thu, 10 Mar 2022 17:57:23 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: Sebastian Shader <sebfumaster(a)aol.com <mailto:sebfumaster@aol.com>> > Cc: "pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>" <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon? > Message-ID: > <CAEAsFmiUpgiieWwpvM11eyY6kE6bdGiWFqFa8pbvPBjtuaoc4w(a)mail.gmail.com <mailto:CAEAsFmiUpgiieWwpvM11eyY6kE6bdGiWFqFa8pbvPBjtuaoc4w@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > I guess I can install catalina on a partition, but I was hoping to use > pdlibbuilder in an easy way, is it possible? -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev May 2022