Re: [PD-dev] pdlibbuilder and static linking pthread by default on Windows.

On Wed, Feb 7, 2018 at 11:50 AM, Lucas Cordiviola wrote: > There were many problems back in 2016 with people that didn't have > pd-extended installed. For them when downloading from deken many objects > didn't work. One of the causes was that those "extended" .dlls where

Re: [PD-dev] pdlibbuilder and static linking pthread by default on Windows.

To return to the original subject of this thread, if I install Pd for Windows from Miller's site I get libwinpthread-1.dll and pthreadVC.dll in Pd/bin. So I don't see why it's necessary to ship either or both along with an external, or to statically link them. It seems to needlessly duplicate code

[PD-dev] Multithreading support for FFT functions

Hi, As IOhannes pointed it in this Github pull request ( https://github.com/pure-data/pure-data/pull/81), the FFT functions in d_fft_fftsg.c are not thread-safe. An easy fix would be to set the static variables TLS (*PERTHREAD*). (It doesn't solve the "size problem" of the original pull request

Re: [PD-dev] pdlibbuilder and static linking pthread by default on Windows.

There are upcoming compilations for w64 and not-too-soon the "double-precision" ones. This will avoid missing pthreads. "-static by default" will also help to not make a mistake and ship an w32 pthread on a w64 pkg. Mensaje telepatico asistido por maquinas. On 2/6/2018 12:43 PM, IOhannes m