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 libwinpthread-1.dll when needed.
There are many chances for this to happen as when we test an compiled [external] it will be working with Pd's libwinpthread-1.dll so we might think that everything is OK. Also people from linux & osx are not really aware that on Windows/MinGW pthread is an specific file.
This in turn will let the [external] survive when Pd, in some future, will start using a future MinGW pthread implementation.
We discussed this but IOhannes & Dan see static linking as something horrible. I see that there's no difference in shipping the file or statically include it in the [external]. I also tested that [externals] that don't use pthread are immune to the -static flag.
Is there something I'm missing? Why not putting a "lifebuoy" by default ?
If a dev does not want -static he/she can override it.
Some thoughts? community ?
I ask this because I care about Windows Pd and [externals].
On 2018-02-06 16:13, Lucas Cordiviola wrote:
Also people from linux & osx are not really aware that on Windows/MinGW pthread is an specific file.
i think most are aware that there is a libpthread.so library. the difference is, that on practically each and any OSX and Linux system, this file will already be installed, because these systems are (virtually) POSIX compliant ("pthread" is the POSIX thread implementation).
This in turn will let the [external] survive when Pd, in some future, will start using a future MinGW pthread implementation.
to put some numbers to the problem:
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.
of these 10 libraries, the following 6 come from the big Pd-extended import, and have not been updated since (and are presumably unmaintained): - hidin - iemxmlrpc - mrpeach (+ net) - pdogg - unauthorized
these two have been re-uploaded since (fwiw, both have been uploaded by me), but miss the libpthread*.dll. - bsaylor - iemnet
and finally these two have been re-uploaded and include a libthread*.dll - maxlib - cyclone
We discussed this but IOhannes & Dan see static linking as something horrible. I see that there's no difference in shipping the file or statically include it in the [external]. I also tested that [externals] that don't use pthread are immune to the -static flag.
Is there something I'm missing? Why not putting a "lifebuoy" by default ?
the more we add to a build system by default, the more fragile it becomes.
https://www.cartoonstock.com/cartoonview.asp?catref=jcen121
If a dev does not want -static he/she can override it.
the alternative suggestion would have been an "opt-in" to allow those people who do want static linking of pthread (or whatever) to set that.
I ask this because I care about Windows Pd and [externals].
it's not like I don't care about Pd and externals to run on Windows. but I also care about maintainable and clean code (e.g. in the common parts of the build system).
gfmdasrt IOhannes
On Tue, Feb 6, 2018 at 10:43 AM, IOhannes m zmoelnig zmoelnig@iem.at 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.
of these 10 libraries, the following 6 come from the big Pd-extended import, and have not been updated since (and are presumably unmaintained):
- hidin
- iemxmlrpc
- mrpeach (+ net)
- pdogg
- unauthorized
I have been workjng on mrpeach in sourceforge svn recently, so I _am_
maintaining it, although pthreads was probably imported from somewhere else. AFAIK it's only needed for some of the net objects like [tcpserver]. I am really not sure how to build an external on a Windows system. All the docs in pdinfo are several years old. The readme here: https://github.com/pure-data/pure-data/tree/master/msw talks about some hybrid build system on wine using mingw and msw but gives no indication of how to set it up. I don't see why one must use a linux box to compile for Windows, it's just offputting. On Windows, I usually give up trying after a day or so of filling my drive with mingw and cygwin and getting nowhere. I also try to build using Visual Studio, but there again the versions are usually incompatible with whatever pd.lib was built with. As I've mentioned before, the c runtime libraries that mingw and msw link against are not compatible, and possibly neither are the pthread dlls. It would be nice if the 'official' tool chain for building externals that work with vanilla Pd on a Windows machine in 2018 could be explicitly documented somewhere.
Martin
On 2/6/2018 1:06 PM, Martin Peach wrote:
It would be nice if the 'official' tool chain for building externals that work with vanilla Pd on a Windows machine in 2018 could be explicitly documented somewhere.
I think that for your lib is most likely that with the new 0.5.0 https://github.com/pure-data/pd-lib-builder and Msys2 you will get both 32-bit and the brand new 64-bit builds.
As of pthread, you can open your [external].dll with http://www.dependencywalker.com/, there are 32 (to check 32bit dlls) and 64 bit versions. You will get lots of info when you open your [external].dll. On win10 there are many false missing deps warnings. There you will find which pthread.dll your build is using. If you build with Msys2 this is libwinpthread-1.dll
To add confusion this pthread has two incompatible 32 and 64 versions with the same name and are located in the %/mingw32/bin and %/mingw64/bin
Mensaje telepatico asistido por maquinas.
On 2018-02-06 17:06, Martin Peach wrote:
On Tue, Feb 6, 2018 at 10:43 AM, IOhannes m zmoelnig zmoelnig@iem.at 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.
of these 10 libraries, the following 6 come from the big Pd-extended import, and have not been updated since (and are presumably unmaintained):
- hidin
- iemxmlrpc
- mrpeach (+ net)
- pdogg
- unauthorized
I have been workjng on mrpeach in sourceforge svn recently, so I _am_
maintaining it,
oops indeed. sorry if my message came through as "declaring 'mrpeach' dead upstream", it was not intended. i'm pretty well aware of you actively maintaining the "mrpeach" library (and i happen to have uploaded a new snapshot of pd-mrpeach to Debian just 3 days ago). i rephrased the mail several times and i'm pretty sure that in one iteration it had "mrpeach" not counted as "unmaintained".
having said that, the mrpeach version that people can download via deken is still the very one taken from Pd-extended. so for the many end-users, it indeed *looks* unmaintained.
The readme here: https://github.com/pure-data/pure-data/tree/master/msw talks about some hybrid build system on wine using mingw and msw but gives no indication of how to set it up
adding to what dan said: we (dan, christof, me) recently put some work into that and there is now a build system that allows to build Pd for Windows both natively on Windows (using MinGW) and via cross-compilation on Linux, without wine & MSVC.
https://github.com/pure-data/pure-data/pull/299
(the PR is still open, but afaict miller likes it)
I don't see why one must use a linux box to compile for Windows, it's just offputting.
the "msw/" directory documents the release procedure of miller and - as the readme puts it - "is a mess". it is rather meant to get a glimpse of what is really going on, rather than a set of instructions to follow to create your own "release of vanilla".
many devs who are used to linux, prefer to do all the work there and cross-compile whenver possible (even if it involves setting up some wine magic, bells and whistles once). at least that's how i feel about it (and given the documented workflow in msw/ it seems others do so as well).
anyhow, PR#299 also adds a lot of documentation to README.txt and msw/README.txt, which basically boils down to an easy to follow guide for the casual coder to compile their own version of Pd for the Win32 platform.
fgdasr IOhannes
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 zmoelnig wrote:
these two have been re-uploaded since (fwiw, both have been uploaded by me), but miss the libpthread*.dll.
- bsaylor
- iemnet
On 2018-02-07 14:45, Lucas Cordiviola wrote:
On 2/6/2018 12:43 PM, IOhannes m zmoelnig wrote:
these two have been re-uploaded since (fwiw, both have been uploaded by me), but miss the libpthread*.dll.
- bsaylor
- iemnet
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. thanks for offering assistance, but i'm pretty sure i can manage.
also please note that "double precision" is totally unrelated to whether pthread is statically linked or not.
gfmsdr IOhannes
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 and possibly introduce version conflicts.
Martin
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 using pthread-GC-2.dll. This file was installed by pd-extended installer on windows system folders.
Attached is a list of missing dlls on 2016.
Now we have included those dlls in each pkg so [externals] work without having pd-extended installed.
The actual libwinpthread-1.dll could change in future MinGWs so externals compiled today may stop working.
Mensaje telepatico asistido por maquinas.
On 2/7/2018 1:20 PM, Martin Peach wrote: 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 and possibly introduce version conflicts.
Martin
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Wed, Feb 7, 2018 at 11:50 AM, Lucas Cordiviola lucarda27@hotmail.com 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 using pthread-GC-2.dll. This file was installed by pd-extended installer on windows system folders.
Attached is a list of missing dlls on 2016.
Now we have included those dlls in each pkg so [externals] work without having pd-extended installed.
The actual libwinpthread-1.dll could change in future MinGWs so externals compiled today may stop working.
Is it possible to just use one pthread dll for all the externals, the one that comes with Pd? They should all have the same functions in them, so it would just be a matter of changing the linker LIBS. In externals/Makefile pthreadGC2 occurs just once at the beginning, this is the one used in mrpeach. I attach a list of all the lpthreads mentioned in all the files in the externals directory (at https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/). Most of them are pthread for linux or MacOS (except iem/iemnet/Makefile:41:LIBS_windows=-lpthread), 18 are pthreadGC and four are pthreadVC. It's possible some of the pthreads are for Windows as well.
Martin
Is it possible to just use one pthread dll for all the externals, the one that comes with Pd?
Yes but they need recompiling (and re-upload to deken).
I'm a "windows native" so i'm just having breakfast on compiling. :)
From the few things that I know is up to the compiler to handle its implementation of pthread.h
Also [externals] can be compiled with VC, Msys1, Msys2, Cygwin ...
So the uploder has to ship the needed pthread.dll
Because the uploader might forget to do so, I'm paranoid.
My paranoia was already explained.
So to avoid this to happen is why i think is better to statically link pthread. This gives the [external] it own way to not depend on Pd's pthread. (actually this is happening to all "extended" era [externals] that were linked against pthreadGC-2.dll)
Mensaje telepatico asistido por maquinas.
On 2/7/2018 3:13 PM, Martin Peach wrote:
On Wed, Feb 7, 2018 at 11:50 AM, Lucas Cordiviola <lucarda27@hotmail.commailto:lucarda27@hotmail.com> 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 using pthread-GC-2.dll. This file was installed by pd-extended installer on windows system folders.
Attached is a list of missing dlls on 2016.
Now we have included those dlls in each pkg so [externals] work without having pd-extended installed.
The actual libwinpthread-1.dll could change in future MinGWs so externals compiled today may stop working.
Is it possible to just use one pthread dll for all the externals, the one that comes with Pd? They should all have the same functions in them, so it would just be a matter of changing the linker LIBS. In externals/Makefile pthreadGC2 occurs just once at the beginning, this is the one used in mrpeach. I attach a list of all the lpthreads mentioned in all the files in the externals directory (at https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/). Most of them are pthread for linux or MacOS (except iem/iemnet/Makefile:41:LIBS_windows=-lpthread), 18 are pthreadGC and four are pthreadVC. It's possible some of the pthreads are for Windows as well.
Martin
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.atmailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
IOhannes m zmoelnig -
Lucas Cordiviola -
Martin Peach