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.
I see, how can we know and how about these from fluidsynth?
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> 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