[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