[PD] linking libs with pd-lib-builder (was Re: fluid~)

Lucas Cordiviola lucarda27 at hotmail.com
Wed Jan 6 09:45:47 CET 2021


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/e04cd572cb1ad177519b8e94f27d7be52c074c62/CMakeLists.txt#L62
>
> 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 at christofressi.com <mailto:info at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210106/50056d98/attachment.html>


More information about the Pd-list mailing list