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/>
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/>
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/>
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/>
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/>
Hi all,
I am searching for a Pd implementation of a doppler effect as realistic as
possible.
Any recommendations?
Any patch/external already made and well tested?
Cheers
FJ
You missed the discussion because it took place in libpd-land: https://github.com/libpd/libpd/issues/336 <https://github.com/libpd/libpd/issues/336>
It was not a decision taken lightly, but it's necessary as Pd's previous "error()" could conflict with libc "error()". The replacement already existed for sometime, so changing calls to "error(...)" with "pd_error(0, ...)" should be equivalent and not break the external in old versions of Pd.
> On Apr 29, 2022, at 12:00 PM, pd-dev-request(a)lists.iem.at wrote:
>
> Message: 2
> Date: Fri, 29 Apr 2022 09:51:48 +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: [PD-dev] error missing in Pd 0.52
> Message-ID: <96224f3ab47171eff50b17d1507974c6d8b13fd5.camel(a)gmail.com <mailto:96224f3ab47171eff50b17d1507974c6d8b13fd5.camel@gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> Hey all
>
> Since 0.52, compiling of some externals fails with an error like:
>
> ~~
> binfile.c:103:9: error: implicit declaration of function 'error' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
> error("binfile: Could not create...");
> ~~~
>
> In 0.51-4, the error function was still defined in m_pd.h. Was 'error'
> deprecated in favor of pd_error?
>
> Sorry, if I missed the related discussions, but I feel introducing
> breaking changes in Pd is generally not done lightly. And I found
> similar issues in active developments like aoo, so I'm probably not the
> only one having missed this.
>
> Roman
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
I just compiled universal Pd on catalina
I had to add the correct -isysroot Cflagshere are the commands I have saved to configure (I'm not sure they're the exact ones I used):
SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/./configure CFLAGS="-arch x86_64 -arch arm64 -isysroot $SDKROOT -mmacosx-version-min=10.6" --host aarch64-apple-darwin"
hope it helps-seb
------------------------------
Date: Sat, 30 Apr 2022 21:50:51 -0300
From: Alexandre Torres Porres <porres(a)gmail.com>
To: Dan Wilcox <danomatika(a)gmail.com>
Cc: pd-dev <pd-dev(a)lists.iem.at>
Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon?
Message-ID:
   <CAEAsFmhzsxKuUxRrUXrf0Z6xc=JaJ6wrcwQ7AEQhhLL8X9J-zA(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Em qui., 10 de mar. de 2022 ?s 19:57, Dan Wilcox <danomatika(a)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
>
> 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/ I believe 12.1
could have been possible already. 12.5 needs Big Sur. Here's a table from
the link
Vers?o do XcodeSistema operacional m?nimo necess?rioSDKArquiteturaDestinos
de implanta??oSimuladorSwift
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 wrote:
>
> Message: 2
> Date: Thu, 10 Mar 2022 17:57:23 -0300
> From: Alexandre Torres Porres <porres(a)gmail.com>
> To: Sebastian Shader <sebfumaster(a)aol.com>
> Cc: "pd-dev(a)lists.iem.at" <pd-dev(a)lists.iem.at>
> Subject: Re: [PD-dev] [PD] how to compile externals for apple silicon?
> Message-ID:
> <CAEAsFmiUpgiieWwpvM11eyY6kE6bdGiWFqFa8pbvPBjtuaoc4w(a)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
> robotcowboy.com
>
>
>
>