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
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
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
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.
>
>
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