hi,On 07/03/2016 08:48 AM, Lucas Cordiviola wrote:> Type “missing” in deken`s search bar.> Then put all dlls in the pd/bin directory.while i appreciate the initiative to provide missing system libraries, ithink this is the wrong way to do it.#1 a deken package should be self-contained.if a given deken package lacks a library (e.g. libpthreadGCC3.dll) thenit should provide that library itself.(alternatively, deken could be (theoretically; practically i see anumber of hurdles) enhanced to explicitely state such dependencies (soinstalling "foo" would also install "pthreadGCC3")#2 a deken package must be installable by deken. the requierement to"then put all the dlls into pd/bin" contradicts this.until deken can be told to install into pd/bin, i think that thoughshall not abuse the deken package system for such things.i'd therefore rather have the 'missingDLLs' package removed frompuredata.info.we *should* come up with a proper solution for the problem though.fmasdrIOhannes Hi IOhannes, I've been thinking on the issue and did some tests that gave good results. First good result is that the missing .dlls placed on the same folder as the external seems to work, I did a couple of tests and both worked. Second, I made a patch that creates objects from every .dll in a given dir, the target dir is obviously the deken PKG extracted folder, this speeds up checking PKGs. And third, I found http://www.dependencywalker.com/ wich provide some useful info about which dll is missing. For example for zexy, “libgnurx-0.dll” is called by matchbox.dll. The patch that I made also gives false errors because some objects need creation args. I attach a zip with the patch along with 2 needed externals. Let me know what you think. I'm thinking on preparing a win10 system to check packages and provide some reports.
Salutti,Lucarda.
Mensaje telepatico asistido por maquinas.
Hi Lucas, why don't you recompile the externals with static libraries?
Le 09/07/2016 à 13:31, Lucas Cordiviola a écrit :
hi, On 07/03/2016 08:48 AM, Lucas Cordiviola wrote: > Type “missing” in deken`s search bar. > Then put all dlls in the pd/bin directory. while i appreciate the initiative to provide missing system libraries, i think this is the wrong way to do it. #1 a deken package should be self-contained. if a given deken package lacks a library (e.g. libpthreadGCC3.dll) then it should provide that library itself. (alternatively, deken could be (theoretically; practically i see a number of hurdles) enhanced to explicitely state such dependencies (so installing "foo" would also install "pthreadGCC3") #2 a deken package must be installable by deken. the requierement to "then put all the dlls into pd/bin" contradicts this. until deken can be told to install into pd/bin, i think that though shall not abuse the deken package system for such things. i'd therefore rather have the 'missingDLLs' package removed from puredata.info. we *should* come up with a proper solution for the problem though. fmasdr IOhannesHi IOhannes,
I've been thinking on the issue and did some tests that gave good results.
First good result is that the missing .dlls placed on the same folder as the external seems to work, I did a couple of tests and both worked.
Second, I made a patch that creates objects from every .dll in a given dir, the target dir is obviously the deken PKG extracted folder, this speeds up checking PKGs.
And third, I found http://www.dependencywalker.com/ wich provide some useful info about which dll is missing. For example for zexy, “libgnurx-0.dll” is called by matchbox.dll.
The patch that I made also gives false errors because some objects need creation args.
I attach a zip with the patch along with 2 needed externals.
Let me know what you think.
I'm thinking on preparing a win10 system to check packages and provide some reports.
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Lucas, why don't you recompile the externals with static libraries? Hi Patrice , I've never compiled anything and also I don't write C code. What does static libraries means? It is adding the system.dll to the object.dll? If that was the case anyway we have to detect which dll needs that. Or are you saying that *you* can recompile all w32 deken packages? Let me know.
Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: colet.patrice@free.fr Date: Sat, 9 Jul 2016 16:42:36 +0200 Subject: Re: [PD] w32 Deken package issues.
Hi Lucas, why don't you recompile the externals with static libraries?
Le 09/07/2016 à 13:31, Lucas Cordiviola a écrit :
hi, On 07/03/2016 08:48 AM, Lucas Cordiviola wrote: > Type “missing” in deken`s search bar. > Then put all dlls in the pd/bin directory. while i appreciate the initiative to provide missing system libraries, i think this is the wrong way to do it. #1 a deken package should be self-contained. if a given deken package lacks a library (e.g. libpthreadGCC3.dll) then it should provide that library itself. (alternatively, deken could be (theoretically; practically i see a number of hurdles) enhanced to explicitely state such dependencies (so installing "foo" would also install "pthreadGCC3") #2 a deken package must be installable by deken. the requierement to "then put all the dlls into pd/bin" contradicts this. until deken can be told to install into pd/bin, i think that though shall not abuse the deken package system for such things. i'd therefore rather have the 'missingDLLs' package removed from puredata.info. we *should* come up with a proper solution for the problem though. fmasdr IOhannesHi IOhannes,
I've been thinking on the issue and did some tests that gave good results.
First good result is that the missing .dlls placed on the same folder as the external seems to work, I did a couple of tests and both worked.
Second, I made a patch that creates objects from every .dll in a given dir, the target dir is obviously the deken PKG extracted folder, this speeds up checking PKGs.
And third, I found http://www.dependencywalker.com/ wich provide some useful info about which dll is missing. For example for zexy, “libgnurx-0.dll” is called by matchbox.dll.
The patch that I made also gives false errors because some objects need creation args.
I attach a zip with the patch along with 2 needed externals.
Let me know what you think.
I'm thinking on preparing a win10 system to check packages and provide some reports.
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-- Patrice Colet fr: 0632660357
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Lucas,
Le 10/07/2016 à 01:32, Lucas Cordiviola a écrit :
/Hi Lucas, why don't you recompile the externals with static libraries?/Hi Patrice ,
I've never compiled anything and also I don't write C code.
What does static libraries means? It is adding the system.dll to the object.dll?
For a static linking we need the .a files, not the .dll that's the hardcore part because if there is no .a we have to import functions with dlltools. That's why I think IOhannes suggested to use first the dll provided by PureData (pthread) at recompilation.
The third party dlls can also be provided by third party softwares (eg: for pdlua install lua5.3 and add luadist lib folder to PureData path).
This also should be indicated by deken during install that we need to add third party software for having things working.
If that was the case anyway we have to detect which dll needs that.
The library dependences names can be found through the linker command line in Makefile prepended with "-l" characters.
Detecting could be done by referencing all system DLL provided by pd-extended and doing a script for detecting those libraries in linking command lines found in pure-data-svn/externals/myexternal/Makefile.
Or are you saying that *you* can recompile all w32 deken packages?
Unfortunately I don't have a consistent windows machine, and little spare time to do that, but I'd like to help windows customers to snap my code.
Let me know.
Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: colet.patrice@free.fr Date: Sat, 9 Jul 2016 16:42:36 +0200 Subject: Re: [PD] w32 Deken package issues.
Hi Lucas, why don't you recompile the externals with static libraries?
Le 09/07/2016 à 13:31, Lucas Cordiviola a écrit :
hi, On 07/03/2016 08:48 AM, Lucas Cordiviola wrote:
Type “missing” in deken`s search bar. Then put all dlls in the pd/bin directory.
while i appreciate the initiative to provide missing system libraries, i think this is the wrong way to do it. #1 a deken package should be self-contained. if a given deken package lacks a library (e.g. libpthreadGCC3.dll) then it should provide that library itself. (alternatively, deken could be (theoretically; practically i see a number of hurdles) enhanced to explicitely state such dependencies (so installing "foo" would also install "pthreadGCC3") #2 a deken package must be installable by deken. the requierement to "then put all the dlls into pd/bin" contradicts this. until deken can be told to install into pd/bin, i think that though shall not abuse the deken package system for such things. i'd therefore rather have the 'missingDLLs' package removed from puredata.info. we *should* come up with a proper solution for the problem though. fmasdr IOhannes
Hi IOhannes,
I've been thinking on the issue and did some tests that gave good
results.
First good result is that the missing .dlls placed on the same folder as the external seems to work, I did a couple of tests and both
worked.
Second, I made a patch that creates objects from every .dll in a
given
dir, the target dir is obviously the deken PKG extracted folder, this speeds up checking PKGs.
And third, I found http://www.dependencywalker.com/ wich provide some useful info about which dll is missing. For example for zexy, “libgnurx-0.dll” is called by matchbox.dll.
The patch that I made also gives false errors because some objects need creation args.
I attach a zip with the patch along with 2 needed externals.
Let me know what you think.
I'm thinking on preparing a win10 system to check packages and
provide
some reports.
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
-- Patrice Colet fr: 0632660357
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
I just realized by reading mrpeach Makefile that linker uses obj files from installed version of PureData, so I've installed pd-0.47-0 and compiled tcpserver.dll with windows 6.1, it's attached, you may find out that this one doesn't need pthreadGC3.dll anymore, if it's true I could make deken packages of externals that only relies on PureData libs.
Le 10/07/2016 16:18, patrice colet a écrit :
Hi Lucas,
Le 10/07/2016 à 01:32, Lucas Cordiviola a écrit :
/Hi Lucas, why don't you recompile the externals with static libraries?/Hi Patrice ,
I've never compiled anything and also I don't write C code.
What does static libraries means? It is adding the system.dll to the object.dll?
For a static linking we need the .a files, not the .dll that's the hardcore part because if there is no .a we have to import functions with dlltools. That's why I think IOhannes suggested to use first the dll provided by PureData (pthread) at recompilation.
The third party dlls can also be provided by third party softwares (eg: for pdlua install lua5.3 and add luadist lib folder to PureData path).
This also should be indicated by deken during install that we need to add third party software for having things working.
If that was the case anyway we have to detect which dll needs that.
The library dependences names can be found through the linker command line in Makefile prepended with "-l" characters.
Detecting could be done by referencing all system DLL provided by pd-extended and doing a script for detecting those libraries in linking command lines found in pure-data-svn/externals/myexternal/Makefile.
Or are you saying that *you* can recompile all w32 deken packages?
Unfortunately I don't have a consistent windows machine, and little spare time to do that, but I'd like to help windows customers to snap my code.
Let me know.
Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: colet.patrice@free.fr Date: Sat, 9 Jul 2016 16:42:36 +0200 Subject: Re: [PD] w32 Deken package issues.
Hi Lucas, why don't you recompile the externals with static libraries?
Le 09/07/2016 à 13:31, Lucas Cordiviola a écrit :
hi, On 07/03/2016 08:48 AM, Lucas Cordiviola wrote:
Type “missing” in deken`s search bar. Then put all dlls in the pd/bin directory.
while i appreciate the initiative to provide missing system libraries, i think this is the wrong way to do it. #1 a deken package should be self-contained. if a given deken package lacks a library (e.g. libpthreadGCC3.dll) then it should provide that library itself. (alternatively, deken could be (theoretically; practically i see a number of hurdles) enhanced to explicitely state such
dependencies (so
installing "foo" would also install "pthreadGCC3") #2 a deken package must be installable by deken. the requierement to "then put all the dlls into pd/bin" contradicts this. until deken can be told to install into pd/bin, i think that though shall not abuse the deken package system for such things. i'd therefore rather have the 'missingDLLs' package removed from puredata.info. we *should* come up with a proper solution for the problem though. fmasdr IOhannes
Hi IOhannes,
I've been thinking on the issue and did some tests that gave good
results.
First good result is that the missing .dlls placed on the same
folder
as the external seems to work, I did a couple of tests and both
worked.
Second, I made a patch that creates objects from every .dll in a
given
dir, the target dir is obviously the deken PKG extracted folder,
this
speeds up checking PKGs.
And third, I found http://www.dependencywalker.com/ wich provide
some
useful info about which dll is missing. For example for zexy, “libgnurx-0.dll” is called by matchbox.dll.
The patch that I made also gives false errors because some objects need creation args.
I attach a zip with the patch along with 2 needed externals.
Let me know what you think.
I'm thinking on preparing a win10 system to check packages and
provide
some reports.
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
-- Patrice Colet fr: 0632660357
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
Hi Patrice,
Thanx for your explanations!!!
I've tested your recompiled [tcpserver] and I get a system error that say pthreadGC2.dll is missing.
Probably it has to be re-compiled?
OTOH if I understand correctly recompiling externals is better *but* placing the third party dlls in the same dir as the externals could become a “good practice”
As recompiling don't cover all cases, its probably Ok to just add some dlls to the dir.
There is usefull info here (not sure how much updated):
https://puredata.info/dev/pd_webwiki/ExternalsInventory
Salutti, Lucarda Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: colet.patrice@free.fr Date: Sun, 10 Jul 2016 18:37:45 +0200 Subject: Re: [PD] w32 Deken package issues.
I just realized by reading mrpeach Makefile that linker uses obj files from installed version of PureData, so I've installed pd-0.47-0 and compiled tcpserver.dll with windows 6.1, it's attached, you may find out that this one doesn't need pthreadGC3.dll anymore, if it's true I could make deken packages of externals that only relies on PureData libs.
Hello,
Le 11/07/2016 à 02:44, Lucas Cordiviola a écrit :
Hi Patrice,
Thanx for your explanations!!!
I've tested your recompiled [tcpserver] and I get a system error that say *pthreadGC2.dll* is missing.
Probably it has to be re-compiled?
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
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.
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?
OTOH if I understand correctly recompiling externals is better *but* placing the third party dlls in the same dir as the externals could become a “good practice”
As recompiling don't cover all cases, its probably Ok to just add some dlls to the dir.
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?
There is usefull info here (not sure how much updated):
https://puredata.info/dev/pd_webwiki/ExternalsInventory
Salutti,
Lucarda
Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: colet.patrice@free.fr Date: Sun, 10 Jul 2016 18:37:45 +0200 Subject: Re: [PD] w32 Deken package issues.
I just realized by reading mrpeach Makefile that linker uses obj files from installed version of PureData, so I've installed pd-0.47-0 and compiled tcpserver.dll with windows 6.1, it's attached, you may find out that this one doesn't need pthreadGC3.dll anymore, if it's true I could make deken packages of externals that only relies on PureData libs.
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?
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, Ive 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 your 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/binThis is why I think is best to include the third party Dll in the deken package, along with the objects Dlls
Mensaje telepatico asistido por maquinas.
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.
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.
Perhaps I wasn`t clear, pthreadGC2.dll inside mrpeach folder renders OPERATIONAL [tcpclient] and other objects. This conform IOhannes intention that deken pkgs should be self operational, I.e no need to place anything outside the external folder.
Mensaje telepatico asistido por maquinas.
Subject: Re: [PD] w32 Deken package issues. To: lucarda27@hotmail.com; pd-list@lists.iem.at From: colet.patrice@free.fr Date: Mon, 11 Jul 2016 16:11:26 +0200
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.
Le 11/07/2016 16:26, Lucas Cordiviola a écrit :
Perhaps I wasn`t clear, pthreadGC2.dll inside mrpeach folder renders OPERATIONAL [tcpclient] and other objects.
This conform IOhannes intention that deken pkgs should be self operational, I.e no need to place anything outside the external folder.
Ok I get it, that's quite cool but, so there will be copies of the same lib into each external folder needing it?
This way we don't have to recompile anything, that's not bad.
Ok I get it, that's quite cool but, so there will be copies of the same lib into each external folder needing it? Yes sure but that's ok. This way we don't have to recompile anything, that's not bad. I think that yes, but I have to do more tests.I'm testing on win8.1 and win10, not sure if it works on earlier Os. Mensaje telepatico asistido por maquinas.
I see that in the svn repository, externals/Makefile calls for pthreadGC2 when building with MinGW, while Miller's pd-0.47-1 makefile.mingw calls for pthread. And the last pd-extended for Windows has only pthreadVC.dll in its bin directory. pd-046-7 for Windows has pthreadVC.dll as well as pthreadVC.lib and libwinpthread-1,dll. So it seems that pthreadGC2.dll is not needed, but I'm not sure why in pd-extended, -lpthreadGC2 ends up linking against pthreadVC.dll. Am I missing something?
Martin
On Mon, Jul 11, 2016 at 10:52 AM, Lucas Cordiviola lucarda27@hotmail.com wrote:
*Ok I get it, that's quite cool but, so there will be copies of the same * *lib into each external folder needing it?*
Yes sure but that's ok.
*This way we don't have to recompile anything, that's not bad.*
I think that yes, but I have to do more tests. I'm testing on win8.1 and win10, not sure if it works on earlier Os.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I see that in the svn repository, externals/Makefile calls for pthreadGC2 when building with MinGW, while Miller's pd-0.47-1 makefile.mingw calls for pthread. And the last pd-extended for Windows has only pthreadVC.dll in its bin directory. Surely extended installer placed pthreadGC2 in the system32 folder or its equivalent sysWOW64 pd-046-7 for Windows has pthreadVC.dll as well as pthreadVC.lib and libwinpthread-1,dll.
So it seems that pthreadGC2.dll is not needed, but I'm not sure why in pd-extended, -lpthreadGC2 ends up linking against pthreadVC.dll. Am I missing something?
Surely its not linking with pthreadVC because win8.1 say GC2 is missing and the object cant be created. Win10 machines don't give that info. When downloading a deken package on a system that dont have extended installed (which in turn does NOT have certain Dlls on system32) lots of Objects can't be created.
Apparently this can be solved including the needed third party Dlls in the same dir as the Objects.
Mensaje telepatico asistido por maquinas.
From: chakekatzil@gmail.com Date: Mon, 11 Jul 2016 11:50:00 -0400 To: pd-list@lists.iem.at Subject: Re: [PD] w32 Deken package issues.
I see that in the svn repository, externals/Makefile calls for pthreadGC2 when building with MinGW, while Miller's pd-0.47-1 makefile.mingw calls for pthread. And the last pd-extended for Windows has only pthreadVC.dll in its bin directory. pd-046-7 for Windows has pthreadVC.dll as well as pthreadVC.lib and libwinpthread-1,dll. So it seems that pthreadGC2.dll is not needed, but I'm not sure why in pd-extended, -lpthreadGC2 ends up linking against pthreadVC.dll. Am I missing something?
Martin
On Mon, Jul 11, 2016 at 10:52 AM, Lucas Cordiviola lucarda27@hotmail.com wrote:
Ok I get it, that's quite cool but, so there will be copies of the same lib into each external folder needing it? Yes sure but that's ok. This way we don't have to recompile anything, that's not bad. I think that yes, but I have to do more tests.I'm testing on win8.1 and win10, not sure if it works on earlier Os. Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mon, Jul 11, 2016 at 12:53 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
*I see that in the svn repository, externals/Makefile calls for pthreadGC2 when building with MinGW, while Miller's pd-0.47-1 makefile.mingw calls for pthread. And the last pd-extended for Windows has only pthreadVC.dll in its bin directory.*
Surely extended installer placed pthreadGC2 in the system32 folder or its equivalent sysWOW64
Yes you're right. I have pthreadGC2.dll and libpthread-2.dll in C:\Windows\SysWOW64. (On a Windows10 machine that was upgraded from Windows7). I wonder if compiling the externals with VC would use the pthreadVC.dll in pd/bin. There seems to be no other copy of pthreadVC.dll on my system. As I understand it, vanilla is built with VC. In the past I built my own externals with VC. Extended used MinGW but I was never able to get a working setup myself.
Martin
I think that the goal here is to have Deken packages self “operational”, not needing Dlls outside its folder. Here's a list of all Dlls that were used by Extended 0.44: (1) Since all of these have to be included in the appropriate Deken pkg, I think its not necessary to recompile externals. I understand what you mean by using vanilla`s VS, but there would be lots of cases where the Dlls have to be included because there are no substitutes in the target computer. The good news is that the Dlls can be placed in the same folder as the externals (I did a couple of tests, have to make more)
(1): libdca-0.dlllibdl.dlllibfftw3-3.dlllibfftw3f-3.dlllibfreetype-6.dlllibgavl-1.dlllibgcc_s_dw2-1.dlllibgnurx-0.dlllibjack.dlllibjpeg.dlllibmp3lame-0.dlllibogg-0.dlllibopenjpeg-2.dlllibpng-3.dlllibpng12-0.dlllibsndfile-1.dlllibstdc++-6.dlllibtheora-0.dlllibtheoradec-1.dlllibtheoraenc-1.dlllibtiff-3.dlllibtiffxx-3.dlllibvorbis-0.dlllibvorbisenc-2.dlllibvorbisfile-3.dlllibx264-116.dlllibz-1.dllmsvcr71.dllpthreadGC2.dll
Mensaje telepatico asistido por maquinas.
From: chakekatzil@gmail.com Date: Mon, 11 Jul 2016 13:49:37 -0400 Subject: Re: [PD] w32 Deken package issues. To: lucarda27@hotmail.com CC: pd-list@lists.iem.at
On Mon, Jul 11, 2016 at 12:53 PM, Lucas Cordiviola lucarda27@hotmail.com wrote:
I see that in the svn repository, externals/Makefile calls for pthreadGC2 when building with MinGW, while Miller's pd-0.47-1 makefile.mingw calls for pthread. And the last pd-extended for Windows has only pthreadVC.dll in its bin directory. Surely extended installer placed pthreadGC2 in the system32 folder or its equivalent sysWOW64
Yes you're right. I have pthreadGC2.dll and libpthread-2.dll in C:\Windows\SysWOW64. (On a Windows10 machine that was upgraded from Windows7). I wonder if compiling the externals with VC would use the pthreadVC.dll in pd/bin. There seems to be no other copy of pthreadVC.dll on my system. As I understand it, vanilla is built with VC. In the past I built my own externals with VC. Extended used MinGW but I was never able to get a working setup myself.
Martin
Hello,
Le 11/07/2016 à 19:49, Martin Peach a écrit :
I wonder if compiling the externals with VC would use the pthreadVC.dll in pd/bin. There seems to be no other copy of pthreadVC.dll on my system. As I understand it, vanilla is built with VC. In the past I built my own externals with VC. Extended used MinGW but I was never able to get a working setup myself.
linking against pthreadVC seems to work on my windows 6.1 machine, externals/Makefiles finds pthreadVC.lib in pd dir installed in %programfiles%
I don't know yet if this work also in more recent version of windows.
I'm compiling on windows MinGW with the msys set up proposed in puredata.info, almost all your objects can be compiled, I couldn't have osc to work AFAIR.
On a windows10 machine, I've tried once puredata-svn/externals/mrpeach compilation with netbeans, but gcc version couldn't find libiberty.
On Wed, 2016-07-13 at 17:22 +0200, patrice colet wrote:
I'm compiling on windows MinGW with the msys set up proposed in puredata.info, almost all your objects can be compiled, I couldn't have osc to work AFAIR.
I uploaded an 'osc' package to Deken (for many platforms, including Windows). Can you test, if this works without having to download another DLL? It worked for me, but I might had the some DLLs from an earlier Pd-extended installation lying around.
The source for this is on: https://github.com/reduzent/pd-mrpeach
It is a clone from read-only git repos provided by IOhannes. The externals/mrpeach branch contains the pristine svn state, the master branch contains my changes.
Roman
Hi Roman, Can you test, if this works without having to downloadanother DLL? http://puredata.info/Members/rdz/software/osc-v0.2~git20151117-(Windows-i386... already tested, its ok, no extra .dll needed. Salutti,Lucarda
Mensaje telepatico asistido por maquinas.
From: reduzent@gmail.com To: pd-list@lists.iem.at Date: Thu, 14 Jul 2016 12:58:00 +0200 Subject: Re: [PD] w32 Deken package issues.
On Wed, 2016-07-13 at 17:22 +0200, patrice colet wrote:
I'm compiling on windows MinGW with the msys set up proposed in puredata.info, almost all your objects can be compiled, I couldn't have osc to work AFAIR.
I uploaded an 'osc' package to Deken (for many platforms, including Windows). Can you test, if this works without having to download another DLL? It worked for me, but I might had the some DLLs from an earlier Pd-extended installation lying around.
The source for this is on: https://github.com/reduzent/pd-mrpeach
It is a clone from read-only git repos provided by IOhannes. The externals/mrpeach branch contains the pristine svn state, the master branch contains my changes.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2016-07-11 16:40, Colet Patrice wrote:
Ok I get it, that's quite cool but, so there will be copies of the same lib into each external folder needing it?
yes. that's the microsoft way to ship dependencies. i think it's best to stick with the microsoft way when using w32 (and even better to not having to use w32).
fgsdm IOhannes
On 2016-07-11 16:40, Colet Patrice wrote:> Ok I get it, that's quite cool but, so there will be copies of the same> lib into each external folder needing it? yes. that's the microsoft way to ship dependencies.i think it's best to stick with the microsoft way when using w32 (andeven better to not having to use w32).fgsdmIOhannes
Lets keep Microsoft out of this, this is a Pd and Pd externals issue. Deken is a primitive tool that just download and extracts, very useful, the problem comes because w32 Deken pkgs were wrongly/naively packed. How does other Os handle Deken package dependencies? There are more than 120 w32 deken pkgs, many of them not fully operational in a 2016 pd situation, I mean without pd-extended installed. Following IOhannes idea that a deken pkg must be self operational it must contain the externals, the help patches and if needed its dependencies (pthread implementation and other .dlls) How we update all w32 Deken pkgs?
Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Tue, 12 Jul 2016 09:41:11 +0200 Subject: Re: [PD] w32 Deken package issues.
On 2016-07-11 16:40, Colet Patrice wrote:
Ok I get it, that's quite cool but, so there will be copies of the same lib into each external folder needing it?
yes. that's the microsoft way to ship dependencies. i think it's best to stick with the microsoft way when using w32 (and even better to not having to use w32).
fgsdm IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2016-07-13 10:12, Lucas Cordiviola wrote:
On 2016-07-12 09:41, IOhannes m zmoelnig wrote:
yes. that's the microsoft way to ship dependencies.
Lets keep Microsoft out of this, this is a Pd and Pd externals issue.
no. we can leave out my rant, but shipping dependencies multiple times *is* the w32 way, and i do think we should follow that path. the alternative - installing 3rd party dependencies to %pd%\bin or even to %System% - is a very good way to break your system.
How we update all w32 Deken pkgs?
this probably sounds a bit obvious: we identify the broken packages, then identify the missing dlls for each. then we repack the packages with the libraries included, and upload them)
i can do the second part (repackaging, re-uploading), if someone wades through the first part (identification of missing parts) and provides the result in a computer-readable form. (there are probably ways to automate the first part using DependencyWalker of similar, but i don't know them)
fgmasdr IOhannes
the result in a computer-readable form. Can you describe the protocol?
(there are probably ways to automate the first part usingDependencyWalker of similar, but i don't know them)
I will spend some time trying to automate this with depwalk, because I already have a slower/harder solution. salutti,Lucarda Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Wed, 13 Jul 2016 10:59:29 +0200 Subject: Re: [PD] w32 Deken package issues.
On 2016-07-13 10:12, Lucas Cordiviola wrote:
On 2016-07-12 09:41, IOhannes m zmoelnig wrote:
yes. that's the microsoft way to ship dependencies.
Lets keep Microsoft out of this, this is a Pd and Pd externals issue.
no. we can leave out my rant, but shipping dependencies multiple times *is* the w32 way, and i do think we should follow that path. the alternative - installing 3rd party dependencies to %pd%\bin or even to %System% - is a very good way to break your system.
How we update all w32 Deken pkgs?
this probably sounds a bit obvious: we identify the broken packages, then identify the missing dlls for each. then we repack the packages with the libraries included, and upload them)
i can do the second part (repackaging, re-uploading), if someone wades through the first part (identification of missing parts) and provides the result in a computer-readable form. (there are probably ways to automate the first part using DependencyWalker of similar, but i don't know them)
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 07/13/2016 11:46 AM, Lucas Cordiviola wrote:
the result in a computer-readable form. Can you describe the protocol?
any text file that i can run through some filters to extract
- which package this refers to (full URL)
- which libraries are missing.
probably something like the attached: <pkgurl> <dep1.dll> <dep2.dll> ...
gfmdsr IOhannes
probably something like the attached:<pkgurl> <dep1.dll> <dep2.dll> ...
Can you provide the first field of each line <pkgurl> ?
Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Wed, 13 Jul 2016 12:06:37 +0200 Subject: Re: [PD] w32 Deken package issues.
On 07/13/2016 11:46 AM, Lucas Cordiviola wrote:
the result in a computer-readable form. Can you describe the protocol?
any text file that i can run through some filters to extract
- which package this refers to (full URL)
- which libraries are missing.
probably something like the attached: <pkgurl> <dep1.dll> <dep2.dll> ...
gfmdsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Can you provide the first field of each line <pkgurl> ?
did you see the attached file?fasdrmIOhannes Yes of course, I think I can handle downloading and testing(1), but Deken has no option for getting the url and searching puredata.info for “externals.zip” gives too many results that I can not start. Do you have any tcl or something for w32 urls? (1) it`s a patch that opens and close all .pd one after the other, if some dll is missing it stops because of the Os dialog. It works on win8.1 and earlier, not win10. And in an clean (no pd-extended installed) machine. Patch attached.
Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Wed, 13 Jul 2016 13:16:26 +0200 Subject: Re: [PD] w32 Deken package issues.
On 2016-07-13 12:51, Lucas Cordiviola wrote:
probably something like the attached:<pkgurl> <dep1.dll> <dep2.dll> ...
Can you provide the first field of each line <pkgurl> ?
did you see the attached file?
fasdrm IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2016-07-13 14:00, Lucas Cordiviola wrote:
Can you provide the first field of each line <pkgurl> ?
did you see the attached file?fasdrmIOhannes Yes of course, I think I can handle downloading and testing(1), but Deken has no option for getting the url and searching puredata.info for “externals.zip”
using the deken-search backend (as used by the plugin) and some awk/grep foo, i created the attached list of deken packages for w32.
fgamsdr IOhannes
Ok, It will take some time until I fill the rest of the fields. Probably I finish next week. Salutti,Lucarda. Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Wed, 13 Jul 2016 14:14:41 +0200 Subject: Re: [PD] w32 Deken package issues.
On 2016-07-13 14:00, Lucas Cordiviola wrote:
Can you provide the first field of each line <pkgurl> ?
did you see the attached file?fasdrmIOhannes Yes of course, I think I can handle downloading and testing(1), but Deken has no option for getting the url and searching puredata.info for “externals.zip”
using the deken-search backend (as used by the plugin) and some awk/grep foo, i created the attached list of deken packages for w32.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi IOhannes. First version filled, it has extra info. Its Ok or I remove not .dll info?
Attached .txt Salutti,Lucarda Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Wed, 13 Jul 2016 12:47:39 +0000 Subject: Re: [PD] w32 Deken package issues.
Ok, It will take some time until I fill the rest of the fields. Probably I finish next week. Salutti,Lucarda. Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Wed, 13 Jul 2016 14:14:41 +0200 Subject: Re: [PD] w32 Deken package issues.
On 2016-07-13 14:00, Lucas Cordiviola wrote:
Can you provide the first field of each line <pkgurl> ?
did you see the attached file?fasdrmIOhannes Yes of course, I think I can handle downloading and testing(1), but Deken has no option for getting the url and searching puredata.info for “externals.zip”
using the deken-search backend (as used by the plugin) and some awk/grep foo, i created the attached list of deken packages for w32.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Notes for the tests: I have to close and restart Pd on each pkg test, if not, there was danger of false test as if a given .dll was loaded previously it remains loaded. In this sense I think there's no problem that there are multiple pthreads.dll as if its already loaded other objects that needs it will have it already loaded. Didn't test it but I think there will be no problems alla “warning multiple pthreads.dll”.
Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Fri, 15 Jul 2016 11:08:20 +0000 Subject: Re: [PD] w32 Deken package issues.
Hi IOhannes. First version filled, it has extra info. Its Ok or I remove not .dll info?
Attached .txt Salutti,Lucarda Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Wed, 13 Jul 2016 12:47:39 +0000 Subject: Re: [PD] w32 Deken package issues.
Ok, It will take some time until I fill the rest of the fields. Probably I finish next week. Salutti,Lucarda. Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Wed, 13 Jul 2016 14:14:41 +0200 Subject: Re: [PD] w32 Deken package issues.
On 2016-07-13 14:00, Lucas Cordiviola wrote:
Can you provide the first field of each line <pkgurl> ?
did you see the attached file?fasdrmIOhannes Yes of course, I think I can handle downloading and testing(1), but Deken has no option for getting the url and searching puredata.info for “externals.zip”
using the deken-search backend (as used by the plugin) and some awk/grep foo, i created the attached list of deken packages for w32.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi IOhannes, using the deken-search backend (as used by the plugin) and some awk/grepfoo, i created the attached list of deken packages for w32.fgamsdrIOhannes
I have already checked 88 packages, around 9 of then needs more in deph analysis. Can you provide another txt with the rest of w32 pkgs that don`t have “w32” in its url? Zexy/2.2.6svn is one of them that were not in the previous .txt, there are more. If possible without including the previously given urls. L Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: zmoelnig@iem.at Date: Wed, 13 Jul 2016 14:14:41 +0200 Subject: Re: [PD] w32 Deken package issues.
On 2016-07-13 14:00, Lucas Cordiviola wrote:
Can you provide the first field of each line <pkgurl> ?
did you see the attached file?fasdrmIOhannes Yes of course, I think I can handle downloading and testing(1), but Deken has no option for getting the url and searching puredata.info for “externals.zip”
using the deken-search backend (as used by the plugin) and some awk/grep foo, i created the attached list of deken packages for w32.
fgamsdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
On 13.07.2016 10:59, IOhannes m zmoelnig wrote:
On 2016-07-13 10:12, Lucas Cordiviola wrote:
On 2016-07-12 09:41, IOhannes m zmoelnig wrote:
yes. that's the microsoft way to ship dependencies.
Lets keep Microsoft out of this, this is a Pd and Pd externals issue.
no. we can leave out my rant, but shipping dependencies multiple times *is* the w32 way, and i do think we should follow that path. the alternative - installing 3rd party dependencies to %pd%\bin or even to %System% - is a very good way to break your system.
Windows is missing a central repository for shared libraries.
Let me take my own package purest_json as an example:
- I can tell Linux users to install liboauth, libcurl, and json-c,
because it is available in central repositories for all distributions.
- I compile these dependencies (and their dependencies) in the
resulting dlls, because there is no user-friendly way to tell users to download the dlls.
- I do not know how to do it in Mac OS X, but as far as I can tell
from pull requests that I have merged, it is more like on Windows than on Linux.
Just my $0.02, Thomas
"From the perspective of communication analysis, government is not an instrument of law and order, but of law and disorder." (Gracchus Gruad in: Robert Shea & Robert A. Wilson, The Golden Apple) http://www.residuum.org/
On 07/14/2016 08:17 PM, Thomas Mayer wrote:
- I compile these dependencies (and their dependencies) in the
resulting dlls, because there is no user-friendly way to tell users to download the dlls.
hmm. i'm not sure i can follow here. i guess you meant "I link these dependencies statically into the resulting dlls" when you wrote "I compile these dependencies into the resulting dlls", as there is no way to "compile" two binaries together. however, the really unclear thing is whether you actually meant static linking (or not).
also, what is wrong with just putting the dependency dlls *besides* the external (as has been suggested).
- I do not know how to do it in Mac OS X, but as far as I can tell
from pull requests that I have merged, it is more like on Windows than on Linux.
i don't know about your pull requests, but OSX uses the unix way to resolve dependencies (just like linux): the resulting binary (your external) has a notion of where to look for a given dependency, and if that fails it will search the system paths.
see [1] and [2] on how to create an externals that looks for dependencies besides that externals (original code is from hc)
[1] http://gem.iem.at/documentation/faq/how-do-i-make-library-dependencies-local... [2] https://github.com/iem-projects/pd-iem/blob/master/kitchen/pastyroll-osx.sh
On 15.07.2016 12:17, IOhannes m zmölnig wrote:
On 07/14/2016 08:17 PM, Thomas Mayer wrote:
- I compile these dependencies (and their dependencies) in the
resulting dlls, because there is no user-friendly way to tell users to download the dlls.
hmm. i'm not sure i can follow here. i guess you meant "I link these dependencies statically into the resulting dlls" when you wrote "I compile these dependencies into the resulting dlls", as there is no way to "compile" two binaries together. however, the really unclear thing is whether you actually meant static linking (or not).
Yes, I meant staic linking.
also, what is wrong with just putting the dependency dlls *besides* the external (as has been suggested).
There was a bug in earlier versions of Pd (up to 0.43 I think), that Pd did not look in the same folder for a dependency. Before that, I had a shared library, but have removed it. But that can now safely be reverted, as I make new packages available from deken, and deken is bundled with Pd 0.47.
- I do not know how to do it in Mac OS X, but as far as I can
tell from pull requests that I have merged, it is more like on Windows than on Linux.
i don't know about your pull requests, but OSX uses the unix way to resolve dependencies (just like linux): the resulting binary (your external) has a notion of where to look for a given dependency, and if that fails it will search the system paths.
The external has two shell scripts for embedding: https://github.com/residuum/PuRestJson/blob/master/embed-MacOSX-dependencies... https://github.com/residuum/PuRestJson/blob/master/embed-osx-dep-homebrew.sh
I am not sure, if these are needed.
I hope, I could make my thoughts clearer, Thomas
There was a bug in earlier versions of Pd (up to 0.43 I think), thatPd did not look in the same folder for a dependency.
Not sure what you mean.
If you make an external that needs another .dll, for example an mp3 player ext, and you use an 3th party lib like lib-somthing-mp3.dll.
Its a Windows fact that your compiled object “pdmp3.dll” will find “lib-somthing-mp3.dll” if it is in the same dir.
A proof for that is that if you check “pdmp3.dll” with http://www.dependencywalker.com/ it will say its ok if they are both in the same dir. And it will say that it cant find it if its not there (same dir) or on system folders.
Other places that the system will search are for example pd/bin but that`s out of scope for dependencywalker but you get the idea.
Mensaje telepatico asistido por maquinas.
To: pd-list@lists.iem.at From: thomas@residuum.org Date: Fri, 15 Jul 2016 14:10:28 +0200 Subject: Re: [PD] w32 Deken package issues.
On 15.07.2016 12:17, IOhannes m zmölnig wrote:
On 07/14/2016 08:17 PM, Thomas Mayer wrote:
- I compile these dependencies (and their dependencies) in the
resulting dlls, because there is no user-friendly way to tell users to download the dlls.
hmm. i'm not sure i can follow here. i guess you meant "I link these dependencies statically into the resulting dlls" when you wrote "I compile these dependencies into the resulting dlls", as there is no way to "compile" two binaries together. however, the really unclear thing is whether you actually meant static linking (or not).
Yes, I meant staic linking.
also, what is wrong with just putting the dependency dlls *besides* the external (as has been suggested).
There was a bug in earlier versions of Pd (up to 0.43 I think), that Pd did not look in the same folder for a dependency. Before that, I had a shared library, but have removed it. But that can now safely be reverted, as I make new packages available from deken, and deken is bundled with Pd 0.47.
- I do not know how to do it in Mac OS X, but as far as I can
tell from pull requests that I have merged, it is more like on Windows than on Linux.
i don't know about your pull requests, but OSX uses the unix way to resolve dependencies (just like linux): the resulting binary (your external) has a notion of where to look for a given dependency, and if that fails it will search the system paths.
The external has two shell scripts for embedding: https://github.com/residuum/PuRestJson/blob/master/embed-MacOSX-dependencies... https://github.com/residuum/PuRestJson/blob/master/embed-osx-dep-homebrew.sh
I am not sure, if these are needed.
I hope, I could make my thoughts clearer, Thomas -- "Chaney was aware that anything, however small, can get the eye of the media if it's repulsive enough." (Robert Anton Wilson - The Universe Next Door) http://www.residuum.org/
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Am 15. Juli 2016 15:33:24 MESZ, schrieb Lucas Cordiviola lucarda27@hotmail.com:
There was a bug in earlier versions of Pd (up to 0.43 I think), thatPd did not look in the same folder for a dependency.
Not sure what you mean. If you make an external that needs another .dll, for example an mp3 player ext, and you use an 3th party lib like lib-somthing-mp3.dll. Its a Windows fact that your compiled object “pdmp3.dll” will find “lib-somthing-mp3.dll” if it is in the same dir.
It's also a "fact" (afair) that this used to not work. But anyhow, if it works now we shouldn't bother too much about the past.
mfg.ugd.fhj IOhannes
-- Sent from my pdp-11
have to close and restart Pd on each pkg test, if not, there was danger of false test as if a given .dll was loaded previously it remains loaded. In this sense I think there's no problem that there are multiple pthreads.dll as if its already loaded other objects that needs it will have it already loaded. Didn't test it but I think there will be no problems alla “warning multiple pthreads.dll”.
Tested with [cyclone/coll] [maxlib/netclient] both with one pthreadGC2.dll in each folder, no problems at all.
Both [coll] and [netclient] need pthreadGC2.
Mensaje telepatico asistido por maquinas.
On 07/15/2016 07:32 PM, Lucas Cordiviola wrote:
Tested with [cyclone/coll] [maxlib/netclient] both with one pthreadGC2.dll in each folder, *no problems* at all.
and you did your tests with Pd<0.43? because "older versions of Pd" is what thomas (and me) was referring to.
gfmadsr IOhannes
and you did your tests with Pd<0.43?because "older versions of Pd" is what thomas (and me) was referring to. I was not discussing the past, I was just confirming something I feared. Nope, tests on 0.47.1 I will probably test with 0.38 next sunday :) You know that I was testing for dup dlls. Not backwards comp
Mensaje telepatico asistido por maquinas.
Hi IOhannes. Second version filled, this one has completed tests for the pkgs that needed more in depth analysis. Those where tested with DependancyWalker, one of them being iemmatrix. Only Jamona has not been tested, the rest is done.
Attached “deken_w32_filled_2.txt”.
Salutti,Lucarda. Mensaje telepatico asistido por maquinas.
From: lucarda27@hotmail.com To: pd-list@lists.iem.at Date: Fri, 15 Jul 2016 20:25:58 +0000 Subject: Re: [PD] w32 Deken package issues.
and you did your tests with Pd<0.43?because "older versions of Pd" is what thomas (and me) was referring to. I was not discussing the past, I was just confirming something I feared. Nope, tests on 0.47.1 I will probably test with 0.38 next sunday :) You know that I was testing for dup dlls. Not backwards comp
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2016-07-18 02:58, Lucas Cordiviola wrote:
Second version filled, this one has completed tests for the pkgs that needed more in depth analysis
thanks.
. Those where tested with DependancyWalker, one of them being iemmatrix.
so wha is it flagged as "ok"?
Only Jamona has not been tested, the rest is done.
great. whenever i find the time, i will fix the packages.
fgmasdr IOhannes
. Those where tested with DependancyWalker, one of them being iemmatrix.
so wha is it flagged as "ok"?
Because there`s no need for an 3th pty .dll
great.> whenever i find the time, i will fix the packages.
Cool, please post when pkgs are updated.
Note:For the tests I get the 3th pty .dlls from “Pd-0.44.0-extended-windowsxp-i386.zip”, I only had trouble with “libgnurx-0.dll” which was substituted with one I found on the net.
Salutti,Lucarda.
Mensaje telepatico asistido por maquinas.
On 2016-07-18 02:58, Lucas Cordiviola wrote:
Hi IOhannes. Second version filled, this one has completed tests for the pkgs that needed more in depth analysis. Those where tested with DependancyWalker, one of them being iemmatrix. Only Jamona has not been tested, the rest is done.
i've now fixed all the deken packages that were stripped of pd-extended (that's the ones with "0.0.extended" as the version)
this leaves the following unfixed objects:
http://puredata.info/Members/chr15m/plugin~(Windows-i386-32)-externals.zip libdl.dll
here i suspect that the file should be removed anyhow (it was uploaded prior to the v0.0.extended batch; and it lacks a version number)
http://puredata.info/Members/fjkraan/software/cyclone/0.2beta1/cyclone-v0.2b... pthreadGC2.dll http://puredata.info/Members/fjkraan/software/maxlib/1.5.6/maxlib-v1.5.6-(Wi... pthreadGC2.dll http://puredata.info/Members/fjkraan/software/maxlib/1.5.6/maxlib-v1.5.6-(Wi... pthreadGC2.dll
these i leave as an exercise for the packages' maintainer :-)
fgamsrd IOhannes
Great, thanx. IMO leave/fix [plugin~] there.
Mensaje telepatico asistido por maquinas.
this leaves the following unfixed objects:
http://puredata.info/Members/chr15m/plugin~(Windows-i386-32)-externals.zip libdl.dll
On 07/20/2016 04:45 PM, Lucas Cordiviola wrote:
IMO leave/fix [plugin~] there.
what does this mean? leave it as is? OR fix it?
in any case, there is little merit in keeping it around, and there is an open ticket [1] for the removal of it and similar packages.
fgmards IOhannes
Hi,
Lucas Cordiviola schrieb am 15.07.2016 15:33:
There was a bug in earlier versions of Pd (up to 0.43 I think), thatPd did not look in the same folder for a dependency.
Not sure what you mean. If you make an external that needs another .dll, for example an mp3 player ext, and you use an 3th party lib like lib-somthing-mp3.dll. Its a Windows fact that your compiled object “pdmp3.dll” will find “lib-somthing-mp3.dll” if it is in the same dir. A proof for that is that if you check “pdmp3.dll” with http://www.dependencywalker.com/ it will say it
s ok if they are both in the same dir. And it will say that it cant find it if its not there (same dir) or on system folders. Other places that the system will search are for example pd/bin but that`s out of scope for dependencywalker but you get the idea.
Here is the commit that fixed that for Windows: https://github.com/pure-data/pure-data/commit/5dadaf43c9206823b434d11c6cc6c6...
As you can see, that was fixed with 0.43-2, but not with older versions. As there is no harm to keep the old statically linked version, I still keep this, just to be backward compatible.
Hth, Thomas
Here is the commit that fixed that for Windows:> https://github.com/pure-data/pure-data/commit/5dadaf43c9206823b434d11c6cc6c6... > As you can see, that was fixed with 0.43-2, but not with older versions. As there is no> harm to keep the old statically linked version, I still keep this, just to be backward> compatible.> > Hth,> Thomas
Ok, thanx for the explanation.
Mensaje telepatico asistido por maquinas.
Le 12/07/2016 à 09:41, IOhannes m zmoelnig a écrit :
i think it's best to stick with the microsoft way when using w32 (and even better to not having to use w32).
ahah, I didn't notice that pd can actually find lib dep in external's dir, -verbose mode is expressive enough though, sorry for confusion it has involved.
-
Colet Patrice -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
IOhannes zmölnig
-
Lucas Cordiviola -
Martin Peach -
patrice colet
-
Roman Haefeli -
Thomas Mayer