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

2018-02-07 Thread Martin Peach 
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 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
./august/readanysf~/Makefile:23:PD_LDFLAGS =  -L$(GAVLPREFIX)/lib  -lgavl 
-lgmerlin_avdec -lpthread 
./august/readanysf~/Makefile.win:18:LDFLAGS += -lpd -lwsock32 -lkernel32 
-luser32 -lgdi32 -lpthreadGC2 $(GMERLIN_LIBS)
./bbogart/gphoto/makefile:15:-lgphoto2 -lpthread
./build/win/netclient.libs:1:-lwsock32 -lpthreadGC2
./build/win/netdist.libs:1:-lwsock32 -lpthreadGC2
./build/win/netrec.libs:1:-lwsock32 -lpthreadGC2
./build/win/netserver.libs:1:-lwsock32 -lpthreadGC2
./build/win/oggamp~.libs:1:-lwsock32 -lpthreadGC2
./build/win/oggcast~.libs:1:-lwsock32 -lpthreadGC2
./grill/flext/.svn/pristine/f4/f4ac9b6f8222176fb47eddede95bb10bc17ad6f6.svn-base:15:LIBS
 += -lpthreadVC2
./grill/flext/.svn/pristine/f4/f4ac9b6f8222176fb47eddede95bb10bc17ad6f6.svn-base:17:LIBS
 += -lpthreadVC
./grill/flext/buildsys/win/pd/gnumake-mingw.inc:15:LIBS +=  -lpthreadVC2
./grill/flext/buildsys/win/pd/gnumake-mingw.inc:17:LIBS +=  -lpthreadVC
./hardware/itrax2/makefile:14:LIB = -ldl -lm -lpthread
./iem/hdspm_mixer/makefile:8:LIB = -ldl -lm -lpthread
./iem/iemgui/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iemgui/src/makefile_linux:9:LIB = -ldl -lm -lpthread
./iem/iemnet/.svn/pristine/94/94c749b33a349a8a3c122eb8ec15a0d08d514b86.svn-base:41:LIBS_windows=-lpthread
./iem/iemnet/Makefile:41:LIBS_windows=-lpthread
./iem/iem_adaptfilt/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_adaptfilt/src/makefile_lin:8:LIB = -ldl -lm -lpthread
./iem/iem_ambi/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_atan2/src/makefile:8:LIB = -ldl -lm -lpthread
./iem/iem_atan2/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_atan2/src/makefile_linux:8:LIB = -ldl -lm -lpthread
./iem/iem_bin_ambi/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_bin_ambi/src/makefile_linux:8:LIB = -ldl -lm -lpthread
./iem/iem_delay/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_dp/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_dp/src/makefile_linux:9:LIB = -ldl -lm -lpthread
./iem/iem_matrix/src/makefile:8:LIB = -ldl -lm -lpthread
./iem/iem_matrix/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_matrix/src/makefile_linux:8:LIB = -ldl -lm -lpthread
./iem/iem_roomsim/src/makefile:8:LIB = -ldl -lm -lpthread
./iem/iem_roomsim/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_roomsim/src/makefile_linux:8:LIB = -ldl -lm -lpthread
./iem/iem_spec2/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_spec2/src/makefile_linux:8:LIB = -ldl -lm -lpthread
./iem/iem_tab/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/pdoctave/Makefile:8:LIB = -ldl -lm -lpthread
./iemlib/iemlib1/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iemlib/iemlib2/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iemlib/iem_mp3/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iemlib/iem_t3_lib/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./input_noticer/Makefile:19:LINUXLDFLAGS = `pkg-config --libs glib-2.0 hal 
dbus-glib-1` -lpthread -lgthread-2.0 -lglib-2.0
./Makefile:79:-lwsock32 -liphlpapi -lpthreadGC2 -lkernel32 -luser32 -lgdi32 
-lregex -liberty
./maxlib/Makefile:41:LIBS_windows = -lpthread
./moocow/common/m4/ax_pd_external.m4:355:  LIBS="$LIBS -lpd -lwsock32 
-lpthreadGC2 -lkernel32 -luser32 -lgdi32 -lregex"
./moocow/deque/configure:3861:  LIBS="$LIBS -lpd -lwsock32 -lpthreadGC2 
-lkernel32 -luser32 -lgdi32 -lregex"
./moocow/flite/configure:4401:  LIBS="$LIBS -lpd -lwsock32 -lpthreadGC2 
-lkernel32 -luser32 -lgdi32 -lregex"
./moocow/gfsm/configure:20523:  LIBS="$LIBS -lpd -lwsock32 -lpthreadGC2 
-lkernel32 -luser32 -lgdi32 -lregex"
./moocow/locale/configure:3861:  LIBS="$LIBS

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

2018-02-07 Thread Martin Peach 
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.at
https://lists.puredata.info/listinfo/pd-dev

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

2018-02-07 Thread Lucas Cordiviola 
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

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

2018-02-06 Thread Martin Peach 
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.
>
> 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
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

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

2018-02-06 Thread Lucas Cordiviola 

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

-- 
Mensaje telepatico asistido por maquinas.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev