[PD] Windows/MinGW DLL dependencies. Was: cyclone/maxlib-maintenance-(w32)

Fred Jan Kraan fjkraan at xs4all.nl
Sat Jul 30 10:23:19 CEST 2016


On 2016-07-30 12:07 AM, Lucas Cordiviola wrote:
> Thanx Fred:
>
>     />cyclone/coll object also required libgcc_s_dw2-1.dll from the MinGW/.
>
>
> Could you explain why “libgcc_s_dw2-1.dll “ is needed?

Not really. For proper testing you need a Windows machine that has no 
MinGW development kit installed, or at least not in the current PATH. 
Usually when a dll is missing the system shows a popup window stating 
the name of the dll. Here this often doesn't happen. It did once, so I 
knew the name of the dll.
>
> I've become paranoid because that escape my tests, and there *could* be
> other Deken pkgs that need it.
>
> I cant detect it with http://www.dependencywalker.com/ and couldn't
> detected just opening the help patch.
>
> Does “libgcc_s_dw2-1.dll “ is called only when a certain [coll] process
> is triggered ?

The dependency on pthread.h / pthreadGC2.dll was introduced to make 
loading data sets into coll multi-threaded. Loading large data sets 
would cause drop-outs in the audio.

The threaded loading patch came from pd-L2ork and was proposed by Ivica 
Bukvic.

> Any knowledge, thought, ideas are welcomed.
>
My knowledge on the Windows DLL-mechanism is quite limited, but apparently
it is more dynamic than expected. In this specific case threading is used
for file IO operations. But the object fails to load, so all DLLs are
required at load time.

Somehow I assume the MinGW system has a provision to prevent this kind 
of issue. If the compiled binaries can only be run on machines having 
the build system installed, the use of MinGW would be quite limited. 
Time to read the documentation ;-).

At least the MinGW DLLs are licensed as Public Domain of MIT (depending 
on distribution) so redistribution is not an issue.

> Salutti,
> Lucarda
>
Greetings,

Fred Jan
>
> Mensaje telepatico asistido por maquinas.



More information about the Pd-list mailing list