The question is better answered by informing yourself of how dynamic libraries are found by applications on the platform, in this case macOS.
As far as I know, it basically comes down to:
- Applications look in ~/lib, /usr/local/lib, and /usr/lib by default.
- As you've found with Purr Data, an app bundle will also look in Contents/libs.
- Applications will also look in other places listed in environment variables.
- You can fiddle with the search path used per library when it's linked using install_name_tool.
See the docs:
https://developer.apple.com/library/archive/documentation/DeveloperTools/Con... https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/UsingDynamicLibraries.html#//apple_ref/doc/uid/TP40002182-SW10
or
https://developer.apple.com/library/archive/documentation/DeveloperTools/Con... https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html
or lots of posts on SO like
https://stackoverflow.com/questions/38685581/how-to-set-dylib-search-path-os... https://stackoverflow.com/questions/38685581/how-to-set-dylib-search-path-osx
For distributing a plugin like an external via deken, options 1-3 are probably out to some degree. Option 4 however is not easy either as the path set by install_name_tool has to be relatively specific, in my experience. Getting it to work with the dylib sitting "wherever" on someone else machine is not so easy, unfortunately.
Gem makes this work, so I would check how they do it for macOS.
The other, simpler alternative is to statically link fluidsynth into the external. You then have a larger pd_darwin but no dependencies or dylib search paths. If homebrew installs a statically-built libfluidsynth.a to /usr/local/lib, you can use that.
On Dec 12, 2020, at 2:29 AM, pd-list-request@lists.iem.at wrote:
Message: 3 Date: Fri, 11 Dec 2020 22:28:33 -0300 From: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> To: Esteban Viveros <emviveros@gmail.com mailto:emviveros@gmail.com> Cc: Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com>, Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] fluid~ Message-ID: <CAEAsFmh701xsCJ8g95+Tt1=6FE-68kHeHsjdw3shLffQJLT75Q@mail.gmail.com mailto:CAEAsFmh701xsCJ8g95+Tt1=6FE-68kHeHsjdw3shLffQJLT75Q@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
my searching app failed me, I found libfluidsynth.2.dylib in Contents/lib in Purr Data's app!
So yeah, the question still remains, how can we make Pd find this. It failed to do so if it's just in the same folder. And also if we can build the external binary that already has libfluidsynth.2.dylib embedded in it.
cheers
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Maybe it's helpful to look at pd-lib-builder, since it has an option to build a helper shared library. This makes sense if the same functionality is used by several classes and the library is not compiled as a single binary. One example is [iemnet] which contains a helper library called "libiemnet" (for macOS it is actually named "libiemnet.pd_darwin.dylib").
On Linux and macOS, we have to add special linker options to the *external*. This is what pd-lib-builder does:
Linux: -Wl,-rpath,"$$ORIGIN",--enable-new-dtags
macOS: -install_name @loader_path/$(shared.lib)
On Windows, no such things are needed when building the external, instead Pd has to call SetDllDirectory, so that LoadLibrary will look for dependencies in the same folder.
Christof
On 12.12.2020 10:49, Dan Wilcox wrote:
The question is better answered by informing yourself of how dynamic libraries are found by applications on the platform, in this case macOS.
As far as I know, it basically comes down to:
- Applications look in ~/lib, /usr/local/lib, and /usr/lib by default.
- As you've found with Purr Data, an app bundle will also look in
Contents/libs. 3. Applications will also look in other places listed in environment variables. 4. You can fiddle with the search path used per library when it's linked using install_name_tool.
See the docs:
https://developer.apple.com/library/archive/documentation/DeveloperTools/Con... https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/UsingDynamicLibraries.html#//apple_ref/doc/uid/TP40002182-SW10
or
https://developer.apple.com/library/archive/documentation/DeveloperTools/Con... https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html
or lots of posts on SO like
https://stackoverflow.com/questions/38685581/how-to-set-dylib-search-path-os... https://stackoverflow.com/questions/38685581/how-to-set-dylib-search-path-osx
For distributing a plugin like an external via deken, options 1-3 are probably out to some degree. Option 4 however is not easy either as the path set by install_name_tool has to be relatively specific, in my experience. Getting it to work with the dylib sitting "wherever" on someone else machine is not so easy, unfortunately.
Gem makes this work, so I would check how they do it for macOS.
The other, simpler alternative is to statically link fluidsynth into the external. You then have a larger pd_darwin but no dependencies or dylib search paths. If homebrew installs a statically-built  libfluidsynth.a to /usr/local/lib, you can use that.
On Dec 12, 2020, at 2:29 AM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
Message: 3 Date: Fri, 11 Dec 2020 22:28:33 -0300 From: Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> To: Esteban Viveros <emviveros@gmail.com mailto:emviveros@gmail.com> Cc: Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com>, Pd-List <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] fluid~ Message-ID: <CAEAsFmh701xsCJ8g95+Tt1=6FE-68kHeHsjdw3shLffQJLT75Q@mail.gmail.com mailto:CAEAsFmh701xsCJ8g95+Tt1=6FE-68kHeHsjdw3shLffQJLT75Q@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
my searching app failed me, I found libfluidsynth.2.dylib in Contents/lib in Purr Data's app!
So yeah, the question still remains, how can we make Pd find this. It failed to do so if it's just in the same folder. And also if we can build the external binary that already has libfluidsynth.2.dylib embedded in it.
cheers
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12.12.2020 10:49, Dan Wilcox wrote:
The other, simpler alternative is to statically link fluidsynth into the external. You then have a larger pd_darwin but no dependencies or dylib search paths. If homebrew installs a statically-built libfluidsynth.a to /usr/local/lib, you can use that.
That was my intention and preferred solution. And since this wouldn't be
used by any other external, it's fine it's a larger binary!
Em sáb., 12 de dez. de 2020 às 08:17, Christof Ressi info@christofressi.com escreveu:
Maybe it's helpful to look at pd-lib-builder, since it has an option to build a helper shared library.
Yup, I assumed pd-lib-builder could help us with things like that ;)
Em sáb., 12 de dez. de 2020 às 10:27, Dan Wilcox danomatika@gmail.com escreveu:
From: Christof Ressi info@christofressi.com macOS: -install_name @loader_path/$(shared.lib)
I think this line basically says "when loading this dylib, try looking in the same folder." This would be ideal as it means the libfluidsynth.dylib just needs to sit next to fluid~.pd_darwin.
That also works for me, but I'd still prefer to generate a single larger binary with the lib included. Can we do that with pd-lib-builder?
One way or another, I'd need to see an example of a project that does this and makes it work so I can better understand and copy the method. As it is, I only have an idea that it provides a solution, but not really how.
I can also set up a repository for fluid~ on github and people can contribute to fix this.
cheers
Em sáb., 12 de dez. de 2020 às 08:17, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> escreveu: Maybe it's helpful to look at pd-lib-builder, since it has an option to build a helper shared library.
Yup, I assumed pd-lib-builder could help us with things like that ;)
I don't think helper libraries are needed here, that's mainly a local library that's linked from the projects sources files and not necessarily another project. I've used a helper library for some projects where you have two executables which share some of the same classes, for instance.
have only used them for building another project's sources in Pd actually, not port midi and port audio, mainly to avoid their relatively slowly maintained configure scripts.
Em sáb., 12 de dez. de 2020 às 10:27, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> escreveu:
From: Christof Ressi <info@christofressi.com mailto:info@christofressi.com> macOS: -install_name @loader_path/$(shared.lib)
I think this line basically says "when loading this dylib, try looking in the same folder." This would be ideal as it means the libfluidsynth.dylib just needs to sit next to fluid~.pd_darwin.
That also works for me, but I'd still prefer to generate a single larger binary with the lib included. Can we do that with pd-lib-builder?
Just run install_name_tool after building with the relevant options and files, probably via a secondary makefile target. You may need to read up on how makefiles work and the pd-lib-build docs on how the build steps are performed to find the right place to add it.*
One way or another, I'd need to see an example of a project that does this and makes it work so I can better understand and copy the method. As it is, I only have an idea that it provides a solution, but not really how.
- see above
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Em seg., 4 de jan. de 2021 às 18:06, Dan Wilcox danomatika@gmail.com escreveu:
Em sáb., 12 de dez. de 2020 às 10:27, Dan Wilcox danomatika@gmail.com escreveu:
From: Christof Ressi info@christofressi.com macOS: -install_name @loader_path/$(shared.lib)
I think this line basically says "when loading this dylib, try looking in the same folder." This would be ideal as it means the libfluidsynth.dylib just needs to sit next to fluid~.pd_darwin.
That also works for me, but I'd still prefer to generate a single larger binary with the lib included. Can we do that with pd-lib-builder?
Just run install_name_tool after building with the relevant options and files, probably via a secondary makefile target. You may need to read up on how makefiles work and the pd-lib-build docs on how the build steps are performed to find the right place to add it.*
Ok, "install_name_tool" is something new to me, I tested it on my terminal and got something showing it exists for me. Then googling, I found https://stackoverflow.com/questions/33991581/install-name-tool-to-update-a-e...
- which is pretty much what my issue is, but... it seems I still don't
speak the same language to follow any of this... and yeah, I tried reading pd-lib-build docs before all this and no, I don't really know how makefiles work for real, as I've been a spoiled pd-lib-builder user since I started messing with this kind of thing.
By the way, I just published a repository for this at https://github.com/porres/pd-fluidsynth I can build and use the external in my system and all, but still can't distribute it or release it.
I see it sucks to just come and say "hey, I got no idea, can someone please do this for me?", but I assume it could be really easy and I was hoping reviving and distributing this external would be of great interest and benefit to the community in general. Nonetheless, I'm also eager to learn more about these trivial things, as I ended up sucked inside this black hole of development :) so if anyone there wants to have another shot at pointing things out to me, I'm here.
thanks
What happens if you do this in the makefile:
ldlibs = -l:libfluidsynth.2.3.5.dylib -Wl,-R.
you should test if the build runs on another mac, not yours.
Mensaje telepatico asistido por maquinas.
On 1/4/2021 8:00 PM, Alexandre Torres Porres wrote:
Em seg., 4 de jan. de 2021 às 18:06, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> escreveu:
Em sáb., 12 de dez. de 2020 às 10:27, Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>> escreveu:From: Christof Ressi <info@christofressi.com <mailto:info@christofressi.com>> macOS: -install_name @loader_path/$(shared.lib)I think this line basically says "when loading this dylib, try looking in the same folder." This would be ideal as it means the libfluidsynth.dylib just needs to sit next to fluid~.pd_darwin. That also works for me, but I'd still prefer to generate a single larger binary with the lib included. Can we do that with pd-lib-builder?Just run install_name_tool after building with the relevant options and files, probably via a secondary makefile target. You may need to read up on how makefiles work and the pd-lib-build docs on how the build steps are performed to find the right place to add it.*Ok, "install_name_tool" is something new to me, I tested it on my terminal and got something showing it exists for me. Then googling, I found https://stackoverflow.com/questions/33991581/install-name-tool-to-update-a-e... https://stackoverflow.com/questions/33991581/install-name-tool-to-update-a-executable-to-search-for-dylib-in-mac-os-x
- which is pretty much what my issue is, but... it seems I still don't
speak the same language to follow any of this... and yeah, I tried reading pd-lib-build docs before all this and no, I don't really know how makefiles work for real, as I've been a spoiled pd-lib-builder user since I started messing with this kind of thing.
By the way, I just published a repository for this at https://github.com/porres/pd-fluidsynth https://github.com/porres/pd-fluidsynth I can build and use the external in my system and all, but still can't distribute it or release it.
I see it sucks to just come and say "hey, I got no idea, can someone please do this for me?", but I assume it could be really easy and I was hoping reviving and distributing this external would be of great interest and benefit to the community in general. Nonetheless, I'm also eager to learn more about these trivial things, as I ended up sucked inside this black hole of development :) so if anyone there wants to have another shot at pointing things out to me, I'm here.
thanks
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Reading here the 3th section:
https://homepages.inf.ed.ac.uk/imurray2/compnotes/library_linking.txt
you can probably also try option:
export LD_RUN_PATH="."
in the makefile?
I think this is necessary for Linux and macOS. On Windows it will auto work if the object and the lib are in the same dir.
Mensaje telepatico asistido por maquinas.
On 1/4/2021 8:50 PM, Lucas Cordiviola wrote:
What happens if you do this in the makefile:
ldlibs = -l:libfluidsynth.2.3.5.dylib -Wl,-R.
you should test if the build runs on another mac, not yours.
Mensaje telepatico asistido por maquinas. On 1/4/2021 8:00 PM, Alexandre Torres Porres wrote:
Em seg., 4 de jan. de 2021 às 18:06, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> escreveu:
Em sáb., 12 de dez. de 2020 às 10:27, Dan Wilcox <danomatika@gmail.com <mailto:danomatika@gmail.com>> escreveu:From: Christof Ressi <info@christofressi.com <mailto:info@christofressi.com>> macOS: -install_name @loader_path/$(shared.lib)I think this line basically says "when loading this dylib, try looking in the same folder." This would be ideal as it means the libfluidsynth.dylib just needs to sit next to fluid~.pd_darwin. That also works for me, but I'd still prefer to generate a single larger binary with the lib included. Can we do that with pd-lib-builder?Just run install_name_tool after building with the relevant options and files, probably via a secondary makefile target. You may need to read up on how makefiles work and the pd-lib-build docs on how the build steps are performed to find the right place to add it.*Ok, "install_name_tool" is something new to me, I tested it on my terminal and got something showing it exists for me. Then googling, I found https://stackoverflow.com/questions/33991581/install-name-tool-to-update-a-e... https://stackoverflow.com/questions/33991581/install-name-tool-to-update-a-executable-to-search-for-dylib-in-mac-os-x
- which is pretty much what my issue is, but... it seems I still
don't speak the same language to follow any of this... and yeah, I tried reading pd-lib-build docs before all this and no, I don't really know how makefiles work for real, as I've been a spoiled pd-lib-builder user since I started messing with this kind of thing.
By the way, I just published a repository for this at https://github.com/porres/pd-fluidsynth https://github.com/porres/pd-fluidsynth I can build and use the external in my system and all, but still can't distribute it or release it.
I see it sucks to just come and say "hey, I got no idea, can someone please do this for me?", but I assume it could be really easy and I was hoping reviving and distributing this external would be of great interest and benefit to the community in general. Nonetheless, I'm also eager to learn more about these trivial things, as I ended up sucked inside this black hole of development :) so if anyone there wants to have another shot at pointing things out to me, I'm here.
thanks
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em seg., 4 de jan. de 2021 às 21:31, Lucas Cordiviola lucarda27@hotmail.com escreveu:
Reading here the 3th section:
https://homepages.inf.ed.ac.uk/imurray2/compnotes/library_linking.txt
you can probably also try option:
export LD_RUN_PATH="."
in the makefile?
tried it and it builds, but still get the error
Library not loaded: /usr/local/opt/fluid-synth/lib/libfluidsynth.2.dylib Referenced from: /Users/porres/Downloads/fluid~/fluid~.d_fat
I think this is necessary for Linux and macOS. On Windows it will auto work if the object and the lib are in the same dir.
can you try with windows at least?
I get an error
-lc -l:libfluidsynth.2.3.5.dylib -Wl,-R
ld: library not found for -l:libfluidsynth.2.3.5.dylib
clang: *error: *linker command failed with exit code 1 (use -v to see invocation)
The.dylib file is in the same dir as the .c file?
can you try:
-l:libfluidsynth.2.3.5.dylib -Wl,-rpath,"./"
export LD_RUN_PATH="." in the makefile? tried it and it builds, but still get the error Library not loaded: /usr/local/opt/fluid-synth/lib/libfluidsynth.2.dylib Referenced from: /Users/porres/Downloads/fluid~/fluid~.d_fat
hmm, not sure as I'd never done it.
can you try with windows at least?
I have it working:
image1
I tweecked rhe makefile:
class.sources = fluid~.c
define forWindows
cflags += -I../fs-sources/include
ldlibs += -L../fs-sources/lib
endef
~~~~~~~
"fs-sources" conains the extracted package for win64 from
https://github.com/FluidSynth/fluidsynth/releases/tag/v2.1.6
<https://github.com/FluidSynth/fluidsynth/releases/tag/v2.1.6>
the fluid~ external folder has all these dlls:
fluid~.dll
libgobject-2.0-0.dll
libgthread-2.0-0.dll
libinstpatch-2.dll
libintl-8.dll
libsndfile-1.dll
libfluidsynth-2.dll
libglib-2.0-0.dll
Mensaje telepatico asistido por maquinas.
On 1/4/2021 10:24 PM, Alexandre Torres Porres wrote:
>
>
> Em seg., 4 de jan. de 2021 às 21:31, Lucas Cordiviola
> <lucarda27@hotmail.com <mailto:lucarda27@hotmail.com>> escreveu:
>
> Reading here the 3th section:
>
> https://homepages.inf.ed.ac.uk/imurray2/compnotes/library_linking.txt
> <https://homepages.inf.ed.ac.uk/imurray2/compnotes/library_linking.txt>
>
> you can probably also try option:
>
> export LD_RUN_PATH="."
>
> in the makefile?
>
>
> tried it and it builds, but still get the error
>
> Library not loaded: /usr/local/opt/fluid-synth/lib/libfluidsynth.2.dylib
> Referenced from: /Users/porres/Downloads/fluid~/fluid~.d_fat
>
> I think this is necessary for Linux and macOS. On Windows it will
> auto work if the object and the lib are in the same dir.
>
>
> can you try with windows at least?
>
giving it a closer look to
I get an error
-lc -l:libfluidsynth.2.3.5.dylib -Wl,-R
ld: library not found for -l:libfluidsynth.2.3.5.dylib
did you include the last dot to -R?
-l:libfluidsynth.2.3.5.dylib -Wl,-R.
the last dot is vital.
:)
Mensaje telepatico asistido por maquinas.
For the record, me and lucas have been trying things in the background but we didn't find a solution.
Em seg., 4 de jan. de 2021 às 22:54, Lucas Cordiviola lucarda27@hotmail.com escreveu:
I get an error
-lc -l:libfluidsynth.2.3.5.dylib -Wl,-R
ld: library not found for -l:libfluidsynth.2.3.5.dylib clang: *error: *linker command failed with exit code 1 (use -v to see invocation)
The.dylib file is in the same dir as the .c file?
can you try:
-l:libfluidsynth.2.3.5.dylib -Wl,-rpath,"./"
export LD_RUN_PATH="."
in the makefile?tried it and it builds, but still get the error Library not loaded: /usr/local/opt/fluid-synth/lib/libfluidsynth.2.dylib Referenced from: /Users/porres/Downloads/fluid~/fluid~.d_fat
hmm, not sure as I'd never done it.
can you try with windows at least?
I have it working:
[image: image1]
I tweecked rhe makefile:
class.sources = fluid~.c define forWindows cflags += -I../fs-sources/include ldlibs += -L../fs-sources/lib endef ~~~~~~~ "fs-sources" conains the extracted package for win64 from https://github.com/FluidSynth/fluidsynth/releases/tag/v2.1.6 the fluid~ external folder has all these dlls: fluid~.dll libgobject-2.0-0.dll libgthread-2.0-0.dll libinstpatch-2.dll libintl-8.dll libsndfile-1.dll libfluidsynth-2.dll libglib-2.0-0.dll Mensaje telepatico asistido por maquinas. On 1/4/2021 10:24 PM, Alexandre Torres Porres wrote: Em seg., 4 de jan. de 2021 às 21:31, Lucas Cordiviola < lucarda27@hotmail.com> escreveu: > Reading here the 3th section: > > https://homepages.inf.ed.ac.uk/imurray2/compnotes/library_linking.txt > > you can probably also try option: > > export LD_RUN_PATH="." > > in the makefile? > tried it and it builds, but still get the error Library not loaded: /usr/local/opt/fluid-synth/lib/libfluidsynth.2.dylib Referenced from: /Users/porres/Downloads/fluid~/fluid~.d_fat > I think this is necessary for Linux and macOS. On Windows it will auto > work if the object and the lib are in the same dir. > can you try with windows at least? >
Me and Dan have been pointing you to "-install_name @loader_path". Just do what pd-lib-builder does with shared helper libraries. Unfortunately I don't have time to come up and test a complete solution, but if you don't know how makefiles work already, that might be a good reason to start ;-)
Christof
On 05.01.2021 06:11, Alexandre Torres Porres wrote:
For the record, me and lucas have been trying things in the background but we didn't find a solution.
Em seg., 4 de jan. de 2021 às 22:54, Lucas Cordiviola <lucarda27@hotmail.com mailto:lucarda27@hotmail.com> escreveu:
I get an error -lc -l:libfluidsynth.2.3.5.dylib -Wl,-R ld: library not found for -l:libfluidsynth.2.3.5.dylib clang: *error: *linker command failed with exit code 1 (use -v to see invocation)The.dylib file is in the same dir as the .c file? can you try: -l:libfluidsynth.2.3.5.dylib -Wl,-rpath,"./"export LD_RUN_PATH="." in the makefile? tried it and it builds, but still get the error Library not loaded: /usr/local/opt/fluid-synth/lib/libfluidsynth.2.dylib Referenced from: /Users/porres/Downloads/fluid~/fluid~.d_fathmm, not sure as I'd never done it.can you try with windows at least?I have it working: image1 I tweecked rhe makefile: ~~~~~~~~~ class.sources = fluid~.c define forWindows cflags += -I../fs-sources/include ldlibs += -L../fs-sources/lib endef ~~~~~~~ "fs-sources" conains the extracted package for win64 from https://github.com/FluidSynth/fluidsynth/releases/tag/v2.1.6 <https://github.com/FluidSynth/fluidsynth/releases/tag/v2.1.6> the fluid~ external folder has all these dlls: fluid~.dll libgobject-2.0-0.dll libgthread-2.0-0.dll libinstpatch-2.dll libintl-8.dll libsndfile-1.dll libfluidsynth-2.dll libglib-2.0-0.dll Mensaje telepatico asistido por maquinas. On 1/4/2021 10:24 PM, Alexandre Torres Porres wrote:Em seg., 4 de jan. de 2021 às 21:31, Lucas Cordiviola <lucarda27@hotmail.com <mailto:lucarda27@hotmail.com>> escreveu: Reading here the 3th section: https://homepages.inf.ed.ac.uk/imurray2/compnotes/library_linking.txt <https://homepages.inf.ed.ac.uk/imurray2/compnotes/library_linking.txt> you can probably also try option: export LD_RUN_PATH="." in the makefile? tried it and it builds, but still get the error Library not loaded: /usr/local/opt/fluid-synth/lib/libfluidsynth.2.dylib Referenced from: /Users/porres/Downloads/fluid~/fluid~.d_fat I think this is necessary for Linux and macOS. On Windows it will auto work if the object and the lib are in the same dir. can you try with windows at least?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Am 5. Jänner 2021 11:40:36 MEZ schrieb Christof Ressi info@christofressi.com:
I don't have time to come up and test a complete solution,
well here's a complete solution for both Windows and osx. it's the evolution of the original script by Hans and yours truly:
https://git.iem.at/pd/iem-ci/-/tree/master/pd-lib-builder
(the solution being the localdeps.*.sh scripts)
mfg.hft.fsl IOhannes
Sorry, still lost, even with all the hints and references. Been reading it all as careful as possible, the localdeps.*.sh scripts, the pd-lib-builder code and reference. Many stack overflow entries, other articles found on google, wiki stuff, tested many different things and it all failed... just saying cause I wanna make it clear that it's not that I don't wanna bother learning and doing it myself... I just don't know where to start and, frankly, it's getting to an overkill point for something I don't really need right now. This is more for the community and I already provided a repository and I can just upload the binaries telling people they need to install fluidsynth themselves since I don't know how to link this at the moment and get it over with. Anyway, of course anyone can collaborate and fix the building/linking process any time in the future. And I'm still open for references, clues and hints on what to do, where to learn, but I'm afraid I need very clear and descriptive steps on what to do here and where to look.
cheers
Em ter., 5 de jan. de 2021 às 08:43, IOhannes m zmölnig zmoelnig@iem.at escreveu:
Am 5. Jänner 2021 11:40:36 MEZ schrieb Christof Ressi < info@christofressi.com>:
I don't have time to come up and test a complete solution,
well here's a complete solution for both Windows and osx. it's the evolution of the original script by Hans and yours truly:
https://git.iem.at/pd/iem-ci/-/tree/master/pd-lib-builder
(the solution being the
localdeps.*.shscripts)mfg.hft.fsl IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 1/5/21 9:20 PM, Alexandre Torres Porres wrote:
Sorry, still lost, even with all the hints and references. Been reading it all as careful as possible, the localdeps.*.sh scripts,
hmm, it seems that my overly clear documentation within the scripts is still not enough.
the localdeps.*.sh scripts have in their header:
## usage: $0 <binary> [<binary2>...]
and that's just about all you need to know: run those scripts with the (relative) paths to the externals as arguments. the scripts will do the rest.
gfmdsar IOhannes
Ok, seems I got it now :)
thanks for insisting in helping out
Em ter., 5 de jan. de 2021 às 18:08, IOhannes m zmölnig zmoelnig@iem.at escreveu:
hmm, it seems that my overly clear documentation within the scripts is still not enough.
yeah, I'm desperately trying to warn how I don't really speak the language. All I did before was read that script and try to find how you were using name_tool and the other things, and it all just failed. I wasn't aware I could just run the script. And it took me a while to get there even now. I almost needed you to tell me all the steps in detail:
"1- get that script file and put it in the folder you built your external 2- open terminal at that folder run the script by typing "./ localdeps.macos.sh external.extension"
Anyway, at least I think that's what I needed to do :)
the scripts will do the rest.
They sure did a lot of magical stuff and made many dylib appear inside the folder. So I zipped it and tested it in another machine that doesn't have fludsynth installed, and it worked! But I'm not convinced I need ALL the dylib files that poped out.
They are:
libFLAC.8.dylib libfluidsynth.2.dylib libglib-2.0.0.dylib libgthread-2.0.0.dylib libintl.8.dylib libogg.0.dylib libopus.0.dylib libpcre.1.dylib libportaudio.2.dylib libreadline.8.dylib libsndfile.1.dylib libvorbis.0.dylib libvorbisenc.2.dylib
I thought I only need *libfluidsynth.2.dylib* but now if I delete the rest and try to open the external, I do get those errors of missing links. So yeah, maybe I need these all, but I'm not so sure. I checked Purr Data's libs and at least I didn't see 2 of these: libopus.0.dylib & libreadline.8.dylib. Not that it makes that much of a difference just getting rid of these two out of so many.
Anyway, Lucarda said he was having success building for Windows, but I'm not so sure now. Well, my mac build can be found here: https://github.com/porres/pd-fluidsynth/releases/tag/test-1
So others who don't have fluid~ or fluidsynth installed can also try it :)
Well, thanks again for this
cheers
Em ter., 5 de jan. de 2021 às 19:28, Alexandre Torres Porres < porres@gmail.com> escreveu:
Not that it makes that much of a difference just getting rid of these two out of so many.
I still wonder if there's an easy way to just incorporate all of these libs inside the external binary. that would really make it cleaner. But if we have to settle with this, it's fine also...
I mean, it's been mentioned here as an alternative, but I wonder if it's too much hassle and if we'll need to exchange another dozen of emails until I get what I need to do... or until I give up again :)
cheers
I still wonder if there's an easy way to just incorporate all of these libs inside the external binary.
Do you mean static linking? Depends on the dependencies. Some are available as a static library and others are not.
In my "aoo" Pd external, I use the "opus" library, which can be built both as a static and shared library. My build system supports both dynamic and static linking for each dependency. The versions I upload on Deken are all linked statically (i.e. a single binary). For distribution via a system package manager, however, I would choose dynamic linking, since in that case the dependencies are supposed to be installed system-wide.
Personally, I strongly prefer static linking for plugins (like Pd externals). The downside is that you're responsible for providing the correct linker flags, since a static library is just an archive of object files. For complex dependencies, you're better off with linking dynamically and shipping them along side your library.
Christof
On 05.01.2021 23:35, Alexandre Torres Porres wrote:
Em ter., 5 de jan. de 2021 às 19:28, Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> escreveu:
Not that it makes that much of a difference just getting rid of these two out of so many.I still wonder if there's an easy way to just incorporate all of these libs inside the external binary. that would really make it cleaner. But if we have to settle with this, it's fine also...
I mean, it's been mentioned here as an alternative, but I wonder if it's too much hassle and if we'll need to exchange another dozen of emails until I get what I need to do... or until I give up again :)
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em ter., 5 de jan. de 2021 às 20:53, Christof Ressi info@christofressi.com escreveu:
I still wonder if there's an easy way to just incorporate all of these libs inside the external binary.
Do you mean static linking?
guess so :)
Depends on the dependencies. Some are available as a static library and others are not.
I see, how can we know and how about these from fluidsynth?
Personally, I strongly prefer static linking for plugins (like Pd
externals).
seems best for me too!
The downside is that you're responsible for providing the correct linker flags, since a static library is just an archive of object files. For complex dependencies, you're better off with linking dynamically and shipping them along side your library.
I guess I may have come across a complex system with over a dozen libs :/ so if I get things straight, we're better off just keeping it that way?
cheers
I see, how can we know and how about these from fluidsynth?
https://github.com/FluidSynth/fluidsynth/blob/e04cd572cb1ad177519b8e94f27d7b...
The existence of the "BUILD_SHARED_LIBS" option implies that it *should* be possible to build fluidsynth as a static library.
That being said, if fluidsynth itself depends on external (shared) libraries, the original problem persists, because you still would need to link the final binary with those libraries - or make them static as well. Etc.
I guess I may have come across a complex system with over a dozen libs :/ so if I get things straight, we're better off just keeping it that way?
I think so.
Christof
On 06.01.2021 03:39, Alexandre Torres Porres wrote:
Em ter., 5 de jan. de 2021 às 20:53, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> escreveu:
I still wonder if there's an easy way to just incorporate all of these libs inside the external binary.Do you mean static linking?guess so :)
Depends on the dependencies. Some are available as a static library and others are not.I see, how can we know and how about these from fluidsynth?
Personally, I strongly prefer static linking for plugins (like Pd externals).seems best for me too!
The downside is that you're responsible for providing the correct linker flags, since a static library is just an archive of object files. For complex dependencies, you're better off with linking dynamically and shipping them along side your library.I guess I may have come across a complex system with over a dozen libs :/ so if I get things straight, we're better off just keeping it that way?
cheers
This is a question more for IOhannes and Christof:
I'm helping with fluid~ for Windows. I got 2 build methods:
A - download the binaries from fluidsynth for Windows and use that to build, link and ship dependencies. it works perfect for w32 and w64 but i'm not sure if it loads soundfonts compressed in flac/ogg/etc.
B - download the MSYS2 package of fluidsynth and build with that and use IOhannes script to ship dependencies. Works perfect and i think it loads flac/ogg soundfonts but there's a catchup. The 32bit builds does not load correctly because is incompatible with Pd's 32bit "libwinpthread-1.dll". If I place a newer "libwinpthread-1.dll" in Pd/bin it works.
Don't know what to do.
May be add a README.pd to tell w32 users to copy the shipped "libwinpthread-1.dll" to Pd/bin ?
--
Mensaje telepatico asistido por maquinas.
On 1/5/2021 11:54 PM, Christof Ressi wrote:
I see, how can we know and how about these from fluidsynth?
https://github.com/FluidSynth/fluidsynth/blob/e04cd572cb1ad177519b8e94f27d7b...
The existence of the "BUILD_SHARED_LIBS" option implies that it *should* be possible to build fluidsynth as a static library.
That being said, if fluidsynth itself depends on external (shared) libraries, the original problem persists, because you still would need to link the final binary with those libraries - or make them static as well. Etc.
I guess I may have come across a complex system with over a dozen libs :/ so if I get things straight, we're better off just keeping it that way?
I think so.
Christof
On 06.01.2021 03:39, Alexandre Torres Porres wrote:
Em ter., 5 de jan. de 2021 às 20:53, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> escreveu:
I still wonder if there's an easy way to just incorporate all of these libs inside the external binary.Do you mean static linking?guess so :)
Depends on the dependencies. Some are available as a static library and others are not.I see, how can we know and how about these from fluidsynth?
Personally, I strongly prefer static linking for plugins (like Pd externals).seems best for me too!
The downside is that you're responsible for providing the correct linker flags, since a static library is just an archive of object files. For complex dependencies, you're better off with linking dynamically and shipping them along side your library.I guess I may have come across a complex system with over a dozen libs :/ so if I get things straight, we're better off just keeping it that way?
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I have solved it.
@IOhannes your script is pure magic!.
:)
Mensaje telepatico asistido por maquinas.
On 1/6/2021 5:45 AM, Lucas Cordiviola wrote:
This is a question more for IOhannes and Christof:
I'm helping with fluid~ for Windows. I got 2 build methods:
A - download the binaries from fluidsynth for Windows and use that to build, link and ship dependencies. it works perfect for w32 and w64 but i'm not sure if it loads soundfonts compressed in flac/ogg/etc.
B - download the MSYS2 package of fluidsynth and build with that and use IOhannes script to ship dependencies. Works perfect and i think it loads flac/ogg soundfonts but there's a catchup. The 32bit builds does not load correctly because is incompatible with Pd's 32bit "libwinpthread-1.dll". If I place a newer "libwinpthread-1.dll" in Pd/bin it works.
Don't know what to do.
May be add a README.pd to tell w32 users to copy the shipped "libwinpthread-1.dll" to Pd/bin ?
--
Mensaje telepatico asistido por maquinas. On 1/5/2021 11:54 PM, Christof Ressi wrote:
I see, how can we know and how about these from fluidsynth?
https://github.com/FluidSynth/fluidsynth/blob/e04cd572cb1ad177519b8e94f27d7b...
The existence of the "BUILD_SHARED_LIBS" option implies that it *should* be possible to build fluidsynth as a static library.
That being said, if fluidsynth itself depends on external (shared) libraries, the original problem persists, because you still would need to link the final binary with those libraries - or make them static as well. Etc.
I guess I may have come across a complex system with over a dozen libs :/ so if I get things straight, we're better off just keeping it that way?
I think so.
Christof
On 06.01.2021 03:39, Alexandre Torres Porres wrote:
Em ter., 5 de jan. de 2021 às 20:53, Christof Ressi <info@christofressi.com mailto:info@christofressi.com> escreveu:
I still wonder if there's an easy way to just incorporate all of these libs inside the external binary.Do you mean static linking?guess so :)
Depends on the dependencies. Some are available as a static library and others are not.I see, how can we know and how about these from fluidsynth?
Personally, I strongly prefer static linking for plugins (like Pd externals).seems best for me too!
The downside is that you're responsible for providing the correct linker flags, since a static library is just an archive of object files. For complex dependencies, you're better off with linking dynamically and shipping them along side your library.I guess I may have come across a complex system with over a dozen libs :/ so if I get things straight, we're better off just keeping it that way?
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Am 6. Jänner 2021 03:39:00 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
Personally, I strongly prefer static linking for plugins (like Pd
externals).
seems best for me too!
well, apart from bloat (speaking with my system packager hat on), static linking has *legal* implications: you cannot just distribute a binary that statically links a GPL-library under another license (eg the dwtfyw license).
are you prepared for doing your homework here?
mfg.hft.fsl IOhannes
static linking has *legal* implications: you cannot just distribute a binary that statically links a GPL-library under another license (eg the dwtfyw license).
For the sake of clarity, the same is also true for dynamic linking!
IOhannes knows this, of course, I just figured his comment could've accidentally left some people with the impression that it's ok to dynamically link a GPL library to a permissively (or even commerically) licensed project.
Now, libfluidsynth is actually LGPL v2 licensed. The LGPL has an exception which allows to link a LGPL library to a permissively (or commercially) licensed project. Many people seem to think that LGPL only allows for dynamic linking, but it's also possible to link statically under certain (more strict) conditions:
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
***DISCLAIMER***: This is just my understanding of the situation. Anybody feel free to correct me on this!
Christof
On 06.01.2021 09:52, IOhannes m zmölnig wrote:
Am 6. Jänner 2021 03:39:00 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
Personally, I strongly prefer static linking for plugins (like Pd
externals).
seems best for me too!
well, apart from bloat (speaking with my system packager hat on), static linking has *legal* implications: you cannot just distribute a binary that statically links a GPL-library under another license (eg the dwtfyw license).
are you prepared for doing your homework here?
mfg.hft.fsl IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
The license is being respected (I think?). I didn't touch it, see https://github.com/porres/pd-fluidsynth/blob/main/LICENSE.txt and, well, I do think I could make a variation of this in my ELSE library, but I'd keep the license untouched anyway. Thus, the bump in the way is still learning how to statically link a complex project like this...
So, I started a new thread to announce the test builds for mac/windows, but it all seems fine. Now, what about Linux? There's mo magical scripts for linux, why? I guess Linux handles the dependencies nicely via apt-get and stuff, but what about sharing this via deken?
cheers
Em qua., 6 de jan. de 2021 às 09:43, Christof Ressi info@christofressi.com escreveu:
static linking has *legal* implications: you cannot just distribute a binary that statically links a GPL-library
under another license (eg the dwtfyw license). For the sake of clarity, the same is also true for dynamic linking!
IOhannes knows this, of course, I just figured his comment could've accidentally left some people with the impression that it's ok to dynamically link a GPL library to a permissively (or even commerically) licensed project.
Now, libfluidsynth is actually LGPL v2 licensed. The LGPL has an exception which allows to link a LGPL library to a permissively (or commercially) licensed project. Many people seem to think that LGPL only allows for dynamic linking, but it's also possible to link statically under certain (more strict) conditions:
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
***DISCLAIMER***: This is just my understanding of the situation. Anybody feel free to correct me on this!
Christof
On 06.01.2021 09:52, IOhannes m zmölnig wrote:
Am 6. Jänner 2021 03:39:00 MEZ schrieb Alexandre Torres Porres <
porres@gmail.com>:
Personally, I strongly prefer static linking for plugins (like Pd
externals).
seems best for me too!
well, apart from bloat (speaking with my system packager hat on), static
linking has *legal* implications:
you cannot just distribute a binary that statically links a GPL-library
under another license (eg the dwtfyw license).
are you prepared for doing your homework here?
mfg.hft.fsl IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I forgot that ceammc has its own version of fluid~ and it is distributed via deken. Well, I see no dynamic lib for fluidsynth in the package, so I can only assume it loads it statically... not sure if the authors will pick this up here, but I guess I'll ask them directly...
Em qui., 7 de jan. de 2021 às 03:07, Alexandre Torres Porres < porres@gmail.com> escreveu:
The license is being respected (I think?). I didn't touch it, see https://github.com/porres/pd-fluidsynth/blob/main/LICENSE.txt and, well, I do think I could make a variation of this in my ELSE library, but I'd keep the license untouched anyway. Thus, the bump in the way is still learning how to statically link a complex project like this...
So, I started a new thread to announce the test builds for mac/windows, but it all seems fine. Now, what about Linux? There's mo magical scripts for linux, why? I guess Linux handles the dependencies nicely via apt-get and stuff, but what about sharing this via deken?
cheers
Em qua., 6 de jan. de 2021 às 09:43, Christof Ressi < info@christofressi.com> escreveu:
static linking has *legal* implications: you cannot just distribute a binary that statically links a GPL-library
under another license (eg the dwtfyw license). For the sake of clarity, the same is also true for dynamic linking!
IOhannes knows this, of course, I just figured his comment could've accidentally left some people with the impression that it's ok to dynamically link a GPL library to a permissively (or even commerically) licensed project.
Now, libfluidsynth is actually LGPL v2 licensed. The LGPL has an exception which allows to link a LGPL library to a permissively (or commercially) licensed project. Many people seem to think that LGPL only allows for dynamic linking, but it's also possible to link statically under certain (more strict) conditions:
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic
***DISCLAIMER***: This is just my understanding of the situation. Anybody feel free to correct me on this!
Christof
On 06.01.2021 09:52, IOhannes m zmölnig wrote:
Am 6. Jänner 2021 03:39:00 MEZ schrieb Alexandre Torres Porres <
porres@gmail.com>:
Personally, I strongly prefer static linking for plugins (like Pd
externals).
seems best for me too!
well, apart from bloat (speaking with my system packager hat on),
static linking has *legal* implications:
you cannot just distribute a binary that statically links a GPL-library
under another license (eg the dwtfyw license).
are you prepared for doing your homework here?
mfg.hft.fsl IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em seg., 4 de jan. de 2021 às 20:50, Lucas Cordiviola lucarda27@hotmail.com escreveu:
What happens if you do this in the makefile:
ldlibs = -l:libfluidsynth.2.3.5.dylib -Wl,-R.
I get an error
-lc -l:libfluidsynth.2.3.5.dylib -Wl,-R
ld: library not found for -l:libfluidsynth.2.3.5.dylib clang: *error: *linker command failed with exit code 1 (use -v to see invocation)
-
Alexandre Torres Porres -
Christof Ressi -
Dan Wilcox -
IOhannes m zmölnig -
Lucas Cordiviola