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@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:
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
ok, instead of building in my new system, I tried compiling on and old macbook air (it's not the machine I was using a year ago to compile this by the way). This system seems to have built something that works, see https://github.com/porres/pd-fluidsynth/issues/9#issuecomment-1114044528 (where I'm discussing things in portuguese with charles).
I have to see now what is the difference between both outputs.
Em sáb., 30 de abr. de 2022 às 16:46, Alexandre Torres Porres < porres@gmail.com> escreveu:
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@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:
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Ok, both compilations generate the exact same files and the process was the some. Only difference is the setup
air intel, mojave, xcode 11.3.1 (works) pro intel, montrey xcode 13 (nope)
the error I get from the binary generated in the pro is
/Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin: dlopen(/Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin, 10): Library not loaded: @loader_path/libfluidsynth.3.dylib
Referenced from: /Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin Reason: no suitable image found.
Did find: /Users/ale/Downloads/fluidsynth~_pro/./libfluidsynth.3.dylib: cannot load 'libfluidsynth.3.dylib' (load command 0x80000034 is unknown) /Users/ale/Downloads/fluidsynth~_pro/libfluidsynth.3.dylib: cannot load 'libfluidsynth.3.dylib' (load command 0x80000034 is unknown)
So it seems it finds the generated and shipped dylib, but it is corrupted somehow.
Em sáb., 30 de abr. de 2022 às 16:57, Alexandre Torres Porres < porres@gmail.com> escreveu:
ok, instead of building in my new system, I tried compiling on and old macbook air (it's not the machine I was using a year ago to compile this by the way). This system seems to have built something that works, see https://github.com/porres/pd-fluidsynth/issues/9#issuecomment-1114044528 (where I'm discussing things in portuguese with charles).
I have to see now what is the difference between both outputs.
Em sáb., 30 de abr. de 2022 às 16:46, Alexandre Torres Porres < porres@gmail.com> escreveu:
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@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:
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
sorry for so many emails, but now I see that when compiling on monterey I get this warning
ld: warning: dylib (/usr/local/lib/libfluidsynth.dylib) was built for newer macOS version (12.0) than being linked (10.6)
So I guess that's it, when installing fluidsynth for monterey and compiling it there I may run into trouble by loading it in earlier systems like mojave (10.14.6). Makes sense?
I'm dropping support for mac 32 bit externals, but I'd like to have a fat binary that works for mac intell and arm but supports a good/wider range of operating systems...
maybe if I try the minimum OS required to build for mac arm, anyone knows what it is? I think I heard 'catalina' once...
cheers
Em sáb., 30 de abr. de 2022 às 17:09, Alexandre Torres Porres < porres@gmail.com> escreveu:
Ok, both compilations generate the exact same files and the process was the some. Only difference is the setup
air intel, mojave, xcode 11.3.1 (works) pro intel, montrey xcode 13 (nope)
the error I get from the binary generated in the pro is
/Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin: dlopen(/Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin, 10): Library not loaded: @loader_path/libfluidsynth.3.dylib
Referenced from: /Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin Reason: no suitable image found.
Did find: /Users/ale/Downloads/fluidsynth~_pro/./libfluidsynth.3.dylib: cannot load 'libfluidsynth.3.dylib' (load command 0x80000034 is unknown) /Users/ale/Downloads/fluidsynth~_pro/libfluidsynth.3.dylib: cannot load 'libfluidsynth.3.dylib' (load command 0x80000034 is unknown)
So it seems it finds the generated and shipped dylib, but it is corrupted somehow.
Em sáb., 30 de abr. de 2022 às 16:57, Alexandre Torres Porres < porres@gmail.com> escreveu:
ok, instead of building in my new system, I tried compiling on and old macbook air (it's not the machine I was using a year ago to compile this by the way). This system seems to have built something that works, see https://github.com/porres/pd-fluidsynth/issues/9#issuecomment-1114044528 (where I'm discussing things in portuguese with charles).
I have to see now what is the difference between both outputs.
Em sáb., 30 de abr. de 2022 às 16:46, Alexandre Torres Porres < porres@gmail.com> escreveu:
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@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:
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
so, I tried using the dinamic libs from mojave in monterey, it works, but the OS kept bugging me and forcing me to allow them to be loaded like over a dozen times until it could just load things...
I now made fat binary for intel/arm, included the dynamic libs from mojave, for testing.
I tried loading this back on mojave, it failed, I get the same error (load command 0x80000034 is unknown) - so I get the same thing as before when I tried a pd_darwin compiled in monterey with the libs generated from the monterey compilation, which now I can see it is obvious, cause it was compiled in monterey with the proper libs and I swicthed them, so I did nothing new. All I learned is that a new system can load something compiled in an older system... it did work, but with several annoying warnings that the libs weren't allowed.
I'll try Catalina to see if it can create binaries for a wider range.
Em sáb., 30 de abr. de 2022 às 17:33, Alexandre Torres Porres < porres@gmail.com> escreveu:
sorry for so many emails, but now I see that when compiling on monterey I get this warning
ld: warning: dylib (/usr/local/lib/libfluidsynth.dylib) was built for newer macOS version (12.0) than being linked (10.6)
So I guess that's it, when installing fluidsynth for monterey and compiling it there I may run into trouble by loading it in earlier systems like mojave (10.14.6). Makes sense?
I'm dropping support for mac 32 bit externals, but I'd like to have a fat binary that works for mac intell and arm but supports a good/wider range of operating systems...
maybe if I try the minimum OS required to build for mac arm, anyone knows what it is? I think I heard 'catalina' once...
cheers
Em sáb., 30 de abr. de 2022 às 17:09, Alexandre Torres Porres < porres@gmail.com> escreveu:
Ok, both compilations generate the exact same files and the process was the some. Only difference is the setup
air intel, mojave, xcode 11.3.1 (works) pro intel, montrey xcode 13 (nope)
the error I get from the binary generated in the pro is
/Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin: dlopen(/Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin, 10): Library not loaded: @loader_path/libfluidsynth.3.dylib
Referenced from: /Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin Reason: no suitable image found.
Did find: /Users/ale/Downloads/fluidsynth~_pro/./libfluidsynth.3.dylib: cannot load 'libfluidsynth.3.dylib' (load command 0x80000034 is unknown) /Users/ale/Downloads/fluidsynth~_pro/libfluidsynth.3.dylib: cannot load 'libfluidsynth.3.dylib' (load command 0x80000034 is unknown)
So it seems it finds the generated and shipped dylib, but it is corrupted somehow.
Em sáb., 30 de abr. de 2022 às 16:57, Alexandre Torres Porres < porres@gmail.com> escreveu:
ok, instead of building in my new system, I tried compiling on and old macbook air (it's not the machine I was using a year ago to compile this by the way). This system seems to have built something that works, see https://github.com/porres/pd-fluidsynth/issues/9#issuecomment-1114044528 (where I'm discussing things in portuguese with charles).
I have to see now what is the difference between both outputs.
Em sáb., 30 de abr. de 2022 às 16:46, Alexandre Torres Porres < porres@gmail.com> escreveu:
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@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
please find on this link https://github.com/porres/pd-fluidsynth/releases/tag/0.0.0-test a fat binary for mac intel and arm, compiled on monterey with the dinamic libs from this system for testing
I wonder if this works on M1 macs or if it needs its own libs compiled for it...
Em sáb., 30 de abr. de 2022 às 18:33, Alexandre Torres Porres < porres@gmail.com> escreveu:
so, I tried using the dinamic libs from mojave in monterey, it works, but the OS kept bugging me and forcing me to allow them to be loaded like over a dozen times until it could just load things...
I now made fat binary for intel/arm, included the dynamic libs from mojave, for testing.
I tried loading this back on mojave, it failed, I get the same error (load command 0x80000034 is unknown) - so I get the same thing as before when I tried a pd_darwin compiled in monterey with the libs generated from the monterey compilation, which now I can see it is obvious, cause it was compiled in monterey with the proper libs and I swicthed them, so I did nothing new. All I learned is that a new system can load something compiled in an older system... it did work, but with several annoying warnings that the libs weren't allowed.
I'll try Catalina to see if it can create binaries for a wider range.
Em sáb., 30 de abr. de 2022 às 17:33, Alexandre Torres Porres < porres@gmail.com> escreveu:
sorry for so many emails, but now I see that when compiling on monterey I get this warning
ld: warning: dylib (/usr/local/lib/libfluidsynth.dylib) was built for newer macOS version (12.0) than being linked (10.6)
So I guess that's it, when installing fluidsynth for monterey and compiling it there I may run into trouble by loading it in earlier systems like mojave (10.14.6). Makes sense?
I'm dropping support for mac 32 bit externals, but I'd like to have a fat binary that works for mac intell and arm but supports a good/wider range of operating systems...
maybe if I try the minimum OS required to build for mac arm, anyone knows what it is? I think I heard 'catalina' once...
cheers
Em sáb., 30 de abr. de 2022 às 17:09, Alexandre Torres Porres < porres@gmail.com> escreveu:
Ok, both compilations generate the exact same files and the process was the some. Only difference is the setup
air intel, mojave, xcode 11.3.1 (works) pro intel, montrey xcode 13 (nope)
the error I get from the binary generated in the pro is
/Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin: dlopen(/Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin, 10): Library not loaded: @loader_path/libfluidsynth.3.dylib
Referenced from: /Users/ale/Downloads/fluidsynth~_pro/./fluidsynth~.pd_darwin Reason: no suitable image found.
Did find: /Users/ale/Downloads/fluidsynth~_pro/./libfluidsynth.3.dylib: cannot load 'libfluidsynth.3.dylib' (load command 0x80000034 is unknown) /Users/ale/Downloads/fluidsynth~_pro/libfluidsynth.3.dylib: cannot load 'libfluidsynth.3.dylib' (load command 0x80000034 is unknown)
So it seems it finds the generated and shipped dylib, but it is corrupted somehow.
Em sáb., 30 de abr. de 2022 às 16:57, Alexandre Torres Porres < porres@gmail.com> escreveu:
ok, instead of building in my new system, I tried compiling on and old macbook air (it's not the machine I was using a year ago to compile this by the way). This system seems to have built something that works, see https://github.com/porres/pd-fluidsynth/issues/9#issuecomment-1114044528 (where I'm discussing things in portuguese with charles).
I have to see now what is the difference between both outputs.
Em sáb., 30 de abr. de 2022 às 16:46, Alexandre Torres Porres < porres@gmail.com> escreveu:
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@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Am 30. April 2022 21:46:57 MESZ schrieb Alexandre Torres Porres porres@gmail.com:
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@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:
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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
mfg.sfg.jfd IOhannes
Am 30. April 2022 21:46:57 MESZ schrieb Alexandre Torres Porres porres@gmail.com:
There are scripts taken from https://git.iem.at/pd/iem-ci to copy the libs to the same folder as the external.
Please note that my localdeps.macos.sh does not deal with "universal" dependencies.
That is: if your dependency is already "fat", it will use it just fine. But if your dependency library is only "thin" (eg x86_64 only), then the script will not magically embed a fat binary for you.
It seems it's pretty easy to build fat binaries even if your dependencies are only thin. Esp. homebrew does not support building fat libraries, so if you used brew to install your dependencies you might miss some parts for a truly universal package. Sorry for the empty last email...
mfg.sfg.jfd IOhannes
Em dom., 1 de mai. de 2022 às 01:58, IOhannes m zmölnig zmoelnig@iem.at escreveu:
homebrew does not support building fat libraries, so if you used brew to install your dependencies you might miss some parts for a truly universal package.
yup, I used homebrew. And yeah, someone tested my fat (arm/x86_64) fluidsynth~ and it complained about the dependencies, which is something I really suspected it could happen.
So, now I need to find a way to have in my system an universal fluidsynth~ dynamic lib. I guess I'll have to join the fluidsynth list and ask for that. Maybe they can also help me with the other issue where even a x86_64 fluidsynth installed for monterey via homebrew doesn't work in earlier versions of macOS.
Maybe I need to have dependencies for both architectures and make them fat manually? I wonder if that's it and if it's easy. Moreover, I guess I'd need help with people with M1 macs around... (anyone?).
One last problem and question is that newer versions of macOS are really rejecting loading the external because they think the dynamic lib has malware or something. How can I make it seem notarized?
And I know we may have discussed this earlier but I can't find it. How come isn't it just easier to create an external with an included static lib instead of downloading an external with almost a dozen dynamic libs? It seems it would be ideal to me to have a single fat binary with the externals and the libs all together! I also mean this for windows and linux, though I have to say I'm quite ignorant on Linux and don't know about the challenges and also I don't know if people succeeded in providing binaries with included dynamic libs for linux, please tell me if there are any issues.
Thanks a lot
Sorry for the empty last email...
mfg.sfg.jfd IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Sun, 2022-05-01 at 12:56 -0300, Alexandre Torres Porres wrote:
So, now I need to find a way to have in my system an universal fluidsynth~ dynamic lib.
This seems like an unnecessarily hard quest, since homebrew doesn't ship fat.
Wouldn't it be more feasible to build it separately for separate archs? Then you wouldn't have to compile fluidsynth and all its dependencies just to get fat libraries.
Then there is the issue with codesigning that I don't see completely through yet. It seems on arm64/Monterey, I automatically get signed binaries (adhoc signed, equivalent to 'codesign -s -') when building externals. However, when I apply the localdep script to to such an external file, it cannot be loaded afterwards. Pd immediately quits as soon as it loads the external. An already signed binary cannot/shouldnot be modified afterwards.
I figured I had to remove the signature and sign all libraries in one go, the external itself, but also all dylib files that it depends on.
codesign --remove-signature fluidsynth~.pd_darwin *.dylib codesign -s - fluidsynth~.pd_darwn *.dylib
I'm not sure how/if that would work at all, if you have fat builds.
You still ship both archs together by using different extension for the external (.d_arm64 and .d_amd64) and but the dependent libraries into their arch-specific directories (e.g. 'arm64' and 'amd64'). It's just a suggestion, I haven't tried it myself yet.
I guess I'll have to join the fluidsynth list and ask for that. Maybe they can also help me with the other issue where even a x86_64 fluidsynth installed for monterey via homebrew doesn't work in earlier versions of macOS.
I'm not sure this would be the right place to ask. What they provide, works. The issues that the homebrew team is trying to address with their way to do things are probably not related to the source code, but more related to how things work on new Macs.
Maybe I need to have dependencies for both architectures and make them fat manually? I wonder if that's it and if it's easy. Moreover, I guess I'd need help with people with M1 macs around... (anyone?).
One last problem and question is that newer versions of macOS are really rejecting loading the external because they think the dynamic lib has malware or something. How can I make it seem notarized?
I don't know the details, but once you start with signed code, it seems obvious that the whole chain needs to follow, otherwise signing wouldn't make much sense, if you still could easily inject unsigned code.
And I know we may have discussed this earlier but I can't find it. How come isn't it just easier to create an external with an included static lib instead of downloading an external with almost a dozen dynamic libs?
I finally somewhat figured out how to to stuff with dynamic libraries. Don't know what new culprits static libraries would bring. Maybe someone more knowledgeable could answer that?
It seems it would be ideal to me to have a single fat binary with the externals and the libs all together!
Shipping it together seems practical, I agree. I don't think it matters much whether it is separate files or fat bundles.
I also mean this for windows and linux, though I have to say I'm quite ignorant on Linux and don't know about the challenges and also I don't know if people succeeded in providing binaries with included dynamic libs for linux, please tell me if there are any issues.
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.
Roman
Em ter., 3 de mai. de 2022 às 12:40, Roman Haefeli reduzent@gmail.com escreveu:
I guess I'll have to join the fluidsynth list and ask for that. Maybe they can also help me with the other issue where even a x86_64 fluidsynth installed for monterey via homebrew doesn't work in earlier versions of macOS.
I'm not sure this would be the right place to ask. What they provide, works. The issues that the homebrew team is trying to address with their way to do things are probably not related to the source code, but more related to how things work on new Macs.
but they provide pre built stuff at https://github.com/FluidSynth/fluidsynth/releases/tag/v2.2.7
and I already did ask for universal builds and there was some interest where someone said "I'm open to publish those universal binaries with the fluidsynth releases. I could sign them as well" see https://lists.nongnu.org/archive/html/fluid-dev/2022-05/msg00002.html
So, now I need to find a way to have in my system an universal fluidsynth~ dynamic lib.
This seems like an unnecessarily hard quest, since homebrew doesn't ship fat.
It doesn't. Fluidsynth people also told me about macPorts and how it could maybe provide universal binaries, but I couldn't figure it out.
Wouldn't it be more feasible to build it separately for separate archs? Then you wouldn't have to compile fluidsynth and all its dependencies just to get fat libraries.
I'm also open to that, of course if it just gets too hard.
Then there is the issue with codesigning that I don't see completely through yet.
tell me about it, me neither...
It seems on arm64/Monterey, I automatically get signed binaries (adhoc signed, equivalent to 'codesign -s -') when building externals. However, when I apply the localdep script to to such an external file, it cannot be loaded afterwards. Pd immediately quits as soon as it loads the external. An already signed binary cannot/shouldnot be modified afterwards.
I figured I had to remove the signature and sign all libraries in one go, the external itself, but also all dylib files that it depends on.
codesign --remove-signature fluidsynth~.pd_darwin *.dylib codesign -s - fluidsynth~.pd_darwn *.dylib
I'm not sure how/if that would work at all, if you have fat builds.
well, maybe we can get these from the fluidsynth release, but I hear you, I wouldn't have a clue, but I also don't one way or another.
It seems it would be ideal to me to have a single fat binary with the externals and the libs all together!
Shipping it together seems practical, I agree. I don't think it matters much whether it is separate files or fat bundles.
I also mean this for windows and linux, though I have to say I'm quite ignorant on Linux and don't know about the challenges and also I don't know if people succeeded in providing binaries with included dynamic libs for linux, please tell me if there are any issues.
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? :)
Thanks
by the way, maybe you (or anyone else) may want to join a discussion about these things on my reporitory https://github.com/porres/pd-else/issues/1243
On Tue, 2022-05-03 at 14:35 -0300, Alexandre Torres Porres wrote:
Em ter., 3 de mai. de 2022 às 12:40, Roman Haefeli reduzent@gmail.com escreveu:
I guess I'll have to join the fluidsynth list and ask for that. Maybe they can also help me with the other issue where even a x86_64 fluidsynth installed for monterey via homebrew doesn't work in earlier versions of macOS.
I'm not sure this would be the right place to ask. What they provide, works. The issues that the homebrew team is trying to address with their way to do things are probably not related to the source code, but more related to how things work on new Macs.
but they provide pre built stuff at https://github.com/FluidSynth/fluidsynth/releases/tag/v2.2.7
and I already did ask for universal builds and there was some interest where someone said "I'm open to publish those universal binaries with the fluidsynth releases. I could sign them as well" see https://lists.nongnu.org/archive/html/fluid-dev/2022-05/msg00002.html
Well, glad you already asked, then!
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.
Roman
On 5/3/22 17:39, Roman Haefeli wrote:
Then there is the issue with codesigning that I don't see completely through yet. It seems on arm64/Monterey, I automatically get signed binaries (adhoc signed, equivalent to 'codesign -s -') when building externals. However, when I apply the localdep script to to such an external file, it cannot be loaded afterwards. Pd immediately quits as soon as it loads the external. An already signed binary cannot/shouldnot be modified afterwards.
ah interesting. for whatever reasons i've setup our CI to automatically sign all externals after building, though i always thought this to be a superfluous exercise (as Pd should have the permissions to load unsigned libraries). nice to hear that this step is actually useful.
it seems quite obvious that changing the binary (such as changing it's search paths for dependencies, which is what the localdeps.macos.sh script does) will invalidate any code signature (as the entire point of the code signature is to guarantee that nobody has tempered with the binary).
i guess that while Pd has the permission to load *unsigned* externals, macOS still refuses to load *signed* externals with an invalid signature.
so if indeed Monterey (or more likely: the XCode version you are using) automatically does an ad-hoc signing of all produced binaries, this would explain the current behaviour.
it *might* be enough to just run "codesign --remove-signature" on the modified binaries. if you could confirm this, i will update my localdeps script.
gfmadsr IOhannes
On Wed, 2022-05-04 at 08:32 +0200, IOhannes m zmoelnig wrote:
it *might* be enough to just run "codesign --remove-signature" on the modified binaries. if you could confirm this, i will update my localdeps script.
I modified the script so that it:
* removes the signatures and re-signs all libs * added some tweaks so that dependencies end up in a subfolder named $arch
https://github.com/porres/pd-fluidsynth/blob/main/scripts/localdeps.macos.sh
Roman
On 5/4/22 09:14, Roman Haefeli wrote:
On Wed, 2022-05-04 at 08:32 +0200, IOhannes m zmoelnig wrote:
it *might* be enough to just run "codesign --remove-signature" on the modified binaries. if you could confirm this, i will update my localdeps script.
I modified the script so that it:
- removes the signatures and re-signs all libs
- added some tweaks so that dependencies end up in a subfolder named $arch
https://github.com/porres/pd-fluidsynth/blob/main/scripts/localdeps.macos.sh
PRs are always welcome.
however: have you tried to *just* removing the signature, without adding an ad-hoc signature?
mdfasr IOhannes
On Wed, 2022-05-04 at 09:48 +0200, IOhannes m zmoelnig wrote:
On 5/4/22 09:14, Roman Haefeli wrote:
On Wed, 2022-05-04 at 08:32 +0200, IOhannes m zmoelnig wrote:
it *might* be enough to just run "codesign --remove-signature" on the modified binaries. if you could confirm this, i will update my localdeps script.
I modified the script so that it:
* removes the signatures and re-signs all libs * added some tweaks so that dependencies end up in a subfolder named $arch
https://github.com/porres/pd-fluidsynth/blob/main/scripts/localdeps.macos.sh
PRs are always welcome.
however: have you tried to *just* removing the signature, without adding an ad-hoc signature?
I did now. This is what I get on Monterey, when instantiating an unsigned external:
/Users/user/pd-src/workspace/Darwin-arm64- 32/fluidsynth~/fluidsynth~.d_arm64: dlopen(/Users/user/pd- src/workspace/Darwin-arm64-32/fluidsynth~/fluidsynth~.d_arm64, 0x000A): tried: '/Users/user/pd-src/workspace/Darwin-arm64- 32/fluidsynth~/fluidsynth~.d_arm64' (code signature in <C7908FF4-42E1- 3F81-BAEB-B49A23869746> '/Users/user/pd-src/workspace/Darwin-arm64- 32/fluidsynth~/fluidsynth~.d_arm64' not valid for use in process: Trying to load an unsigned library), '/usr/lib/fluidsynth~.d_arm64' (no such file) fluidsynth~ sf2/Famicom ... couldn't create
At least since Monterey, the codesigning seems mandatory.
Roman
Em qua., 4 de mai. de 2022 às 04:48, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
PRs are always welcome.
+1 I wanna keep using your scripts and want to be sure I can always get the latest version you have without the need of modifications.
On Sun, 2022-05-01 at 12:56 -0300, Alexandre Torres Porres wrote:
Maybe I need to have dependencies for both architectures and make them fat manually? I wonder if that's it and if it's easy. Moreover, I guess I'd need help with people with M1 macs around... (anyone?).
Here is a build for arm64 that could be part of combined package (not fat libraries, but separate files):
https://netpd.org/~roman/tmp/fluidsynth~%5bv0.1%5d(Darwin-arm64-32).dek
The dependent libraries reside in a subfolder 'arm64'. The external itself uses the .d_arm64 extension. Doing the same on amd64 would allow to create a combined package supporting two (or more) archs.
I had to adjust the included localdep.macos script for that to work. Also, I added the codesigning to that script.
Here is the PR:
https://github.com/porres/pd-fluidsynth/pull/10
Cheers, Roman
On Wed, 2022-05-04 at 00:00 +0200, Roman Haefeli wrote:
On Sun, 2022-05-01 at 12:56 -0300, Alexandre Torres Porres wrote:
Maybe I need to have dependencies for both architectures and make them fat manually? I wonder if that's it and if it's easy. Moreover, I guess I'd need help with people with M1 macs around... (anyone?).
Here is a build for arm64 that could be part of combined package (not fat libraries, but separate files):
https://netpd.org/~roman/tmp/fluidsynth~%5bv0.1%5d(Darwin-arm64-32).dek
And here the build for macOS amd64:
https://netpd.org/~roman/tmp/fluidsynth~%5bv0.1%5d(Darwin-amd64-32).dek
Built on Catalina (where I currently do not have GUI access), so I tested it on Monterey (M1) with Pd running with Rosetta. I could play sounds from the famicom soundfont.
Roman
Em ter., 3 de mai. de 2022 às 19:22, Roman Haefeli reduzent@gmail.com escreveu:
And here the build for macOS amd64:
https://netpd.org/~roman/tmp/fluidsynth~%5bv0.1%5d(Darwin-amd64-32).dek
Built on Catalina (where I currently do not have GUI access), so I tested it on Monterey (M1) with Pd running with Rosetta. I could play sounds from the famicom soundfont.
Beautiful <3 thanks a lot! Tested on mojave 10.14.6 on a 2013 macbook air and it also works!
Roman
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Sat, 2022-04-30 at 16:46 -0300, Alexandre Torres Porres wrote:
Hi, after more than a year, I'm finally going to release my fluidsynth~ object as part of ELSE.
Why does it have to be part of ELSE? I mean for such a rather difficult external to maintain, wouldn't it make sense to release it separately?
Roman
for one, I'd like to use a decent keyboard GUI in the help example. I wanna have it as part of my tutorial and I wouldn't like to make students download it separately unless I really really have to and there's no other way around it. I don't mind that it's kinda hard and I don't really see how it specially makes things harder for me. Maybe a better point is "hey, what if people just want this and none of the other 450 externals?". That's a better point and, well, at least as it comes as separate binaries one can just grab it.
Nonetheless, it already has a separate repository and I can see the benefit of also having an independent version scheme and a download of its own as a single external over there. In fact, I see that would help when packaging ELSE as I'd just download it and paste into the latest build (I wouldn't have to keep building fluidsynth~ every time).
cheers
Em dom., 1 de mai. de 2022 às 09:41, Roman Haefeli reduzent@gmail.com escreveu:
On Sat, 2022-04-30 at 16:46 -0300, Alexandre Torres Porres wrote:
Hi, after more than a year, I'm finally going to release my fluidsynth~ object as part of ELSE.
Why does it have to be part of ELSE? I mean for such a rather difficult external to maintain, wouldn't it make sense to release it separately?
Roman _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Sun, 2022-05-01 at 12:43 -0300, Alexandre Torres Porres wrote:
for one, I'd like to use a decent keyboard GUI in the help example. I wanna have it as part of my tutorial and I wouldn't like to make students download it separately unless I really really have to and there's no other way around it. I don't mind that it's kinda hard and I don't really see how it specially makes things harder for me. Maybe a better point is "hey, what if people just want this and none of the other 450 externals?". That's a better point and, well, at least as it comes as separate binaries one can just grab it.
Yeah, that's a good point. Having to grab it from ELSE is not a good advice, though, since as part of ELSE I can't do [declare -lib fluidsynth]. I'd have to [declare -path else] for non-obvious reasons. I don't think that nesting libraries is good practice and it might confuse people searching stuff through Deken.
I see your point of having everything nicely integrated. If I'd feel strong enough about this I could upload separate packages for fluidsynth.
Roman
Em dom., 1 de mai. de 2022 às 16:40, Roman Haefeli reduzent@gmail.com escreveu:
Yeah, that's a good point. Having to grab it from ELSE is not a good advice, though, since as part of ELSE I can't do [declare -lib fluidsynth]. I'd have to [declare -path else] for non-obvious reasons. I don't think that nesting libraries is good practice and it might confuse people searching stuff through Deken.
This implies that fluidsynth~ as an external is presumably a nested external library. As if it couldn't be ever considered as part of ELSE or any other library. I know there's been a 'fluid~' external at some point made available on its own, but fluidsynth~ is not fluid~, fluidsynth~ has a distinct design, and there's no reason or rule that it has to be made available on its own.
The last update of ELSE carries [score] objects that I think are really useful to write scores. The fluidsynth~ addition will be great as a counterpart so people can write scores to be played by fluidsynth~ as well as other oscillators from ELSE.
I can see it could be nice/useful/desired to have it as a single external, but so would be many other externals from ELSE. For instance, else has many reverb objects and includes a reverb based on the gigverb algorythm (giga.rev~) as well as anoter based on the freeverb algorithm (free.rev~) - there are single externals in pd also based on both algorythms but the objects in ELSE are not exactly the same and have a different design. Imagine there weren't such objects made available as single externals, why should I make them available as single externals instead of as part of ELSE?
Anyway, deken is able to search for externals inside libraries, so people using deken and searching for fluidsynth~ will find ELSE, and if you have [declare -path else] in your patch you're telling people they should have ELSE...
Now, when I say people could 'grab' from ELSE, i meant it in some cases where they would want to ship projects with prearranged and preinstalled dependencies/externals, so one could just include fluidsynth~ in some 'dependencies' folder and ship it.''
By the way, ceammc has a fluid~ object and it is part of the ceammce single binary pack, so if one just wanted fluid~ they have to include the whole ceammc pack with over 700 externals. I'm just saying I offer an advantage over that with my single binaries for each external.
cheers
-
Alexandre Torres Porres -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Roman Haefeli