Le 11/07/2016 16:04, Lucas Cordiviola a écrit :
/oupse, I didn't see it hidden in wow64 folder, the good new is
that only /
/externals/Makefile have to be tweaked for using pthreadVC.lib in
pd/bin/
Are you sure pthreadVC.lib is going to have longevity?
What if Miller change this?
It's up to Miller, then we tweak Makefile again...
/I think it's fixed now, so I make an archive with all mrpeach
objects I /
/could compile, and send it in a personal mail attachement for
testing in /
/windows10./
No problem, I`ve set a win10 virtual machine.
/The bad new is that my windows machine is dying but might build a
few /
/packages and a externals/Makefile patch before leaving,/
/could you test this package? If I do other packages would you mind /
/trying them before I publish?/
No problem, as fast as I can.
/It's not as simple as that because pd uses to look for external's
third /
/party DLL into system path, not pd path, maybe it's different now?/
I think you`r wrong here, on my tests third party Dlls in the same dir
as the external worked fine(two tests) and Zip versions of pd-extended
(no need to install, unzip and run) method was putting them in pd/bin
This is why I think is best to include the third party Dll in the
deken package, along with the objects Dlls
Yes I forgot to mention the path where resides pd binary, but I did in
the first mails of this thread... But this is same problem, there is no
method in deken to put those dll in pd/bin dir, users have to do this
manually.
Mensaje telepatico asistido por maquinas.
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
