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

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

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

On Tue, Feb 6, 2018 at 10:43 AM, IOhannes m zmoelnig wrote: > > in Pd-extended, there are 10 out of 112 (different) libraries usable on > Windows in the entire deken repositories that have the libpthread > library included, presumably because they actually need this library. > >

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

We have been working on pdlibbuilder and I've proposed static linking pthread by default. https://github.com/pure-data/pd-lib-builder/issues/42 https://github.com/pure-data/pd-lib-builder/issues/36 My motivation on doing such thing is to prevent people from forgetting to ship