Hello,
trying to compile pd vanilla 0.43 on Windows 7 "ultimate" 64 bits I am running into some trouble. I followed the developer>mingw guide from puredata.org. Then trying ./configure using MSYS. It gives: no tcl header found, and a few lines later: no tcl library found, then quits. I did however compile both tcl and tk 8.5 using this guide: http://wiki.tcl.tk/14828, inside MSYS. Adding a --with-tcl=/... to ./configure only gives the note: unrecognized option. Any thoughts how I could overcome these difficulties? I am a bit lost here.
Bye! Menno
There are two build systems still in vanilla, the old one in pd/src/configure.in and the new one in pd/configure.ac. Use the new one. And it probably also needs a patch to work on MinGW. That makes me think, I don't know the status of Pd-vanilla building on MinGW, but Pd-extended is built on Pd-extended every night, so that might be a better bet for you.
.hc
On Nov 1, 2011, at 6:12 PM, Menno van der Woude wrote:
Hello,
trying to compile pd vanilla 0.43 on Windows 7 "ultimate" 64 bits I am running into some trouble. I followed the developer>mingw guide from puredata.org. Then trying ./configure using MSYS. It gives: no tcl header found, and a few lines later: no tcl library found, then quits. I did however compile both tcl and tk 8.5 using this guide: http://wiki.tcl.tk/14828, inside MSYS. Adding a --with-tcl=/... to ./configure only gives the note: unrecognized option. Any thoughts how I could overcome these difficulties? I am a bit lost here.
Bye! Menno
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Using the new method does get me through configure, thank you. I followed the online instuctions for vanilla, sorry for not checking the included readme.
Upon the 'make' command, the build process starts, however quite soon exits. First there are a number of invalid conversions, eg. from 'void*' to 'PaWinMmeStreamInfo'. Then make exits with:
make[2]: *** [libportaudio_la-pa_pa_win_wmme.lo] Error 1 make[2]: Leaving directory '/home/Menno/pd-0.43-0/portaudio' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/Menno/
Then after adding the option --disable-portaudio to ./configure and doing 'make clean' and then again make, there are similar errors, now with 'po' and 'g_canvas'. I am not sure if using cygwin would be better than MSYS, because cygwin gives errors before anythings happens, I think it cannot find the compiler. Will later try to build pd-extended to see if that goes more easily.
Bye, menno
On Wed, Nov 2, 2011 at 4:00 AM, Hans-Christoph Steiner hans@at.or.at wrote:
There are two build systems still in vanilla, the old one in pd/src/configure.in and the new one in pd/configure.ac. Use the new one. And it probably also needs a patch to work on MinGW. That makes me think, I don't know the status of Pd-vanilla building on MinGW, but Pd-extended is built on Pd-extended every night, so that might be a better bet for you.
.hc
On Nov 1, 2011, at 6:12 PM, Menno van der Woude wrote:
Hello,
trying to compile pd vanilla 0.43 on Windows 7 "ultimate" 64 bits I am running into some trouble. I followed the developer>mingw guide from puredata.org. Then trying ./configure using MSYS. It gives: no tcl header found, and a few lines later: no tcl library found, then quits. I did however compile both tcl and tk 8.5 using this guide: http://wiki.tcl.tk/14828, inside MSYS. Adding a --with-tcl=/... to ./configure only gives the note: unrecognized option. Any thoughts how I could overcome these difficulties? I am a bit lost here.
Bye! Menno
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Hello,
Last weekend a friend and I were trying to build double-precision vanilla Pd (Pd-double) with MinGW. After many troubles not to mention here I remembered about makefile.mingw which is in the src/ dir of the distributions. This gave us a build of Pd-double. But it could not start because of missing standard c or cpp libs. I had seen that before when compiling [soundtouch~] with MinGW. There's flags -static-libgcc and -static-libstdc++, or you can include .dll's. Anyhow, I did 'make -f makefile.mingw clean' and compiled again, but now suddenly missing files.... Those files must have been there while the first build succeeded, no? I'll give it another try soon.
Katja
Hello,
----- Mail original -----
De: "katja" katjavetter@gmail.com À: pd-dev@iem.at Envoyé: Mercredi 2 Novembre 2011 10:38:33 Objet: Re: [PD-dev] help compiling pd 0.43 on Windows 7
Hello,
Last weekend a friend and I were trying to build double-precision vanilla Pd (Pd-double) with MinGW. After many troubles not to mention here I remembered about makefile.mingw which is in the src/ dir of the distributions. This gave us a build of Pd-double. But it could not start because of missing standard c or cpp libs. I had seen that before when compiling [soundtouch~] with MinGW. There's flags -static-libgcc and -static-libstdc++, or you can include .dll's.
I've also found out that externals would need theses flags during compile process, so maybe it would be better to include the dll.
Anyhow, I did 'make -f makefile.mingw clean' and compiled again, but now suddenly missing files.... Those files must have been there while the first build succeeded, no? I'll give it another try soon.
which files?
Katja
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Gave it another try this weekend: building vanilla pd on windows.
Though I once had a pd build using makefile.mingw, this must have been a stroke of luck, a fortunate sequence of operations which I don't know how to reproduce. Instead, I now used the 'new build system' with a few adaptations. These adaptations were derived from a patch file for pd-extended by Patrice Colet and Hans Christoph Steiner. The patch (the one for vanilla, attached, beware that it has windows style line endings) takes care of the following:
- definition 'cc=g++' is no longer applied, and some errors triggered by c files in the port audio section now become warnings - pd-watchdog is disabled for Mingw - pd~ is disabled for windows
The build was done with Mingw. Even with the patched build system it is still a fair pain i.t.a. to build vanilla pd on windows, specially when compared to building on Linux. A lot of .dll's and header files must be collected and copied into the appropriate directories of the build tree. In order to download the asio sdk one is supposed to fill a form with all personal info's when subscribing as Steinberg third party developer. Some .dll's and headers can be copied from a vanilla Pd windows binary distribution. The following .dll's must be copied from the Mingw binaries into Pd's bin/ directory, they're not in Pd binary distributions:
- libgcc_s_dw2-1.dll - libstdc++-6.dll - libpthread-2.dll
I've not tested the build other than with the audio and midi test, as I'm now heading for a pd-double build for windows, and for sure there's something to fix in the audio interface files before pd-double will work. To be continued.
Katja
I think Miller doesn't use MinGW, so building vanilla on Windows is probably easiest using MSVC like he does. Pd-extended builds nightly (when the server is up) using the pd/src/makefile.mingw.
As for the included .dlls, that happens in packages/win32_inno/Makefile. That seems more an issue of packaging.
.hc
On Nov 28, 2011, at 11:32 AM, katja wrote:
Gave it another try this weekend: building vanilla pd on windows.
Though I once had a pd build using makefile.mingw, this must have been a stroke of luck, a fortunate sequence of operations which I don't know how to reproduce. Instead, I now used the 'new build system' with a few adaptations. These adaptations were derived from a patch file for pd-extended by Patrice Colet and Hans Christoph Steiner. The patch (the one for vanilla, attached, beware that it has windows style line endings) takes care of the following:
- definition 'cc=g++' is no longer applied, and some errors triggered
by c files in the port audio section now become warnings
- pd-watchdog is disabled for Mingw
- pd~ is disabled for windows
The build was done with Mingw. Even with the patched build system it is still a fair pain i.t.a. to build vanilla pd on windows, specially when compared to building on Linux. A lot of .dll's and header files must be collected and copied into the appropriate directories of the build tree. In order to download the asio sdk one is supposed to fill a form with all personal info's when subscribing as Steinberg third party developer. Some .dll's and headers can be copied from a vanilla Pd windows binary distribution. The following .dll's must be copied from the Mingw binaries into Pd's bin/ directory, they're not in Pd binary distributions:
- libgcc_s_dw2-1.dll
- libstdc++-6.dll
- libpthread-2.dll
I've not tested the build other than with the audio and midi test, as I'm now heading for a pd-double build for windows, and for sure there's something to fix in the audio interface files before pd-double will work. To be continued.
Katja <new-build-system-vanilla-Mingw.patch>_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: katja katjavetter@gmail.com Cc: pd-dev@iem.at Sent: Monday, November 28, 2011 12:37 PM Subject: Re: [PD-dev] help compiling pd 0.43 on Windows 7
I think Miller doesn't use MinGW, so building vanilla on Windows is probably easiest using MSVC like he does.
Um... is MSVC free?
Pd-extended builds nightly (when the server is up) using the pd/src/makefile.mingw.
As for the included .dlls, that happens in packages/win32_inno/Makefile. That seems more an issue of packaging.
.hc
On Nov 28, 2011, at 11:32 AM, katja wrote:
Gave it another try this weekend: building vanilla pd on windows.
Though I once had a pd build using makefile.mingw, this must have been a stroke of luck, a fortunate sequence of operations which I don't know how to reproduce. Instead, I now used the 'new build system'
with
a few adaptations. These adaptations were derived from a patch file for pd-extended by Patrice Colet and Hans Christoph Steiner. The patch (the one for vanilla, attached, beware that it has windows style line endings) takes care of the following:
- definition 'cc=g++' is no longer applied, and some errors
triggered
by c files in the port audio section now become warnings
- pd-watchdog is disabled for Mingw
- pd~ is disabled for windows
The build was done with Mingw. Even with the patched build system it is still a fair pain i.t.a. to build vanilla pd on windows, specially when compared to building on Linux. A lot of .dll's and header files must be collected and copied into the appropriate directories of the build tree. In order to download the asio sdk one is supposed to fill a form with all personal info's when subscribing as Steinberg third party developer. Some .dll's and headers can be copied from a vanilla Pd windows binary distribution. The following .dll's must be copied from the Mingw binaries into Pd's bin/ directory, they're not in Pd binary distributions:
- libgcc_s_dw2-1.dll
- libstdc++-6.dll
- libpthread-2.dll
I've not tested the build other than with the audio and midi test, as I'm now heading for a pd-double build for windows, and for sure there's something to fix in the audio interface files before pd-double will work. To be continued.
Katja
<new-build-system-vanilla-Mingw.patch>_______________________________________________
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: Hans-Christoph Steiner hans@at.or.at; katja katjavetter@gmail.com; "pd-dev@iem.at" pd-dev@iem.at Sent: Monday, November 28, 2011 2:23 PM Subject: Re: [PD-dev] help compiling pd 0.43 on Windows 7
Um... is MSVC free?
Same deal as Microsoft Windows as a whole...
Right, but does it cost extra money on top of a Microsoft OS, or does it come pre-installed?
cheers M
On 2011-11-28 15:08, Jonathan Wilkes wrote:
Um... is MSVC free?
Same deal as Microsoft Windows as a whole...
Right, but does it cost extra money on top of a Microsoft OS, or does it come pre-installed?
Neither. The "Express" editions are free. Visual C++ 2010 Express seems to have everything you need to build Pd.
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cp...
Martin
----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: "pd-dev@iem.at" pd-dev@iem.at Sent: Monday, November 28, 2011 4:57 PM Subject: Re: [PD-dev] help compiling pd 0.43 on Windows 7
On 2011-11-28 15:08, Jonathan Wilkes wrote:
Um... is MSVC free?
Same deal as Microsoft Windows as a whole...
Right, but does it cost extra money on top of a Microsoft OS, or does it
come pre-installed?
Neither. The "Express" editions are free. Visual C++ 2010 Express seems to have everything you need to build Pd.
http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cp...
Ah, ok. Thanks.
-Jonathan
Martin
On 2011-11-28 12:37, Hans-Christoph Steiner wrote:
I think Miller doesn't use MinGW, so building vanilla on Windows is probably easiest using MSVC like he does. Pd-extended builds nightly (when the server is up) using the pd/src/makefile.mingw.
It seems like the latest Windows nightly build is from November 3 and after November 4 there are not even any logs...
Martin
On Nov 28, 2011, at 2:20 PM, Martin Peach wrote:
On 2011-11-28 12:37, Hans-Christoph Steiner wrote:
I think Miller doesn't use MinGW, so building vanilla on Windows is probably easiest using MSVC like he does. Pd-extended builds nightly (when the server is up) using the pd/src/makefile.mingw.
It seems like the latest Windows nightly build is from November 3 and after November 4 there are not even any logs...
Sorry, I haven't gotten around to rebooting the Windows build server. It crashed a while ago. I should get to it tomorrow.
.hc
----------------------------------------------------------------------------
“We must become the change we want to see. - Mahatma Gandhi
On Mon, Nov 28, 2011 at 6:37 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I think Miller doesn't use MinGW, so building vanilla on Windows is probably easiest using MSVC like he does. Pd-extended builds nightly (when the server is up) using the pd/src/makefile.mingw.
Oow, I was in the assumption that 'new build system' was the preferred way for autobuilds. Well then I have to make it work with makefile.mingw. One purpose of my pathetic efforts is to get pd-double built this way so we can have pd-double-extended test builds for windows one day.
It's so weird that makefile.mingw doesn't create makefile.dependencies, it only re-creates an empty makefile.dependencies when performing a clean. So I have to fool it with a dummy. Is there a better way to get this working? On OSX by the way, makefile.dependencies is always created with 'old build system', but it's empty sometimes, and filled with paths other times. In both cases the build will work. What is this mysterious behaviour?
Makefile.mingw for vanilla seems to be outdated, some elements from makefile.mingw for pd-extended have to be incorporated to make it work. When s_utf8.c is added to SRC, and -lpthreadGC2 is replaced by -lpthread in LIBS, a build is at least produced. Is -lpthread compatible with the windows autobuild configuration?
Is there a way to produce a 'local build' somehow with makefile.mingw? Like 'old build system' can do it without install, and 'new build system' can do it with option --prefix for configure?
Katja
On Nov 28, 2011, at 5:12 PM, katja wrote:
On Mon, Nov 28, 2011 at 6:37 PM, Hans-Christoph Steiner hans@at.or.at wrote:
I think Miller doesn't use MinGW, so building vanilla on Windows is probably easiest using MSVC like he does. Pd-extended builds nightly (when the server is up) using the pd/src/makefile.mingw.
Oow, I was in the assumption that 'new build system' was the preferred way for autobuilds. Well then I have to make it work with makefile.mingw. One purpose of my pathetic efforts is to get pd-double built this way so we can have pd-double-extended test builds for windows one day.
It's so weird that makefile.mingw doesn't create makefile.dependencies, it only re-creates an empty makefile.dependencies when performing a clean. So I have to fool it with a dummy. Is there a better way to get this working? On OSX by the way, makefile.dependencies is always created with 'old build system', but it's empty sometimes, and filled with paths other times. In both cases the build will work. What is this mysterious behaviour?
Makefile.mingw for vanilla seems to be outdated, some elements from makefile.mingw for pd-extended have to be incorporated to make it work. When s_utf8.c is added to SRC, and -lpthreadGC2 is replaced by -lpthread in LIBS, a build is at least produced. Is -lpthread compatible with the windows autobuild configuration?
Is there a way to produce a 'local build' somehow with makefile.mingw? Like 'old build system' can do it without install, and 'new build system' can do it with option --prefix for configure?
The new build system is almost ready for nightly Windows builds, but not quite. So the Pd-extended nightly builds still use pd/src/makefile.mingw.
If you want to work on this, then I think you'll need to port all of the new build system stuff from pd-extended to pd-double, where it works on Windows/MinGW. Otherwise, you'll just be recreating that work.
The PdLab build Windows machine has both -lpthread and -lpthreadGC2, but -lpthread is the preferred route and is standard in the latest MinGW.
.hc
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On Tue, Nov 29, 2011 at 12:57 AM, Hans-Christoph Steiner hans@at.or.at wrote:
The new build system is almost ready for nightly Windows builds, but not quite. So the Pd-extended nightly builds still use pd/src/makefile.mingw.
If you want to work on this, then I think you'll need to port all of the new build system stuff from pd-extended to pd-double, where it works on Windows/MinGW. Otherwise, you'll just be recreating that work.
Think I've got the essential bits ported by now, for both methods. Only thing is, I need to manually create makefile.dependencies before makefile.mingw can do it's work. That is not ok. A diff between pure-data / pd-extended makefile.mingw doesn't point to a solution. Is there some other element involved?
Katja
On Tuesday, November 29, 2011 1:56 AM, "katja" katjavetter@gmail.com wrote:
On Tue, Nov 29, 2011 at 12:57 AM, Hans-Christoph Steiner hans@at.or.at wrote:
The new build system is almost ready for nightly Windows builds, but not quite. So the Pd-extended nightly builds still use pd/src/makefile.mingw.
If you want to work on this, then I think you'll need to port all of the new build system stuff from pd-extended to pd-double, where it works on Windows/MinGW. Otherwise, you'll just be recreating that work.
Think I've got the essential bits ported by now, for both methods. Only thing is, I need to manually create makefile.dependencies before makefile.mingw can do it's work. That is not ok. A diff between pure-data / pd-extended makefile.mingw doesn't point to a solution. Is there some other element involved?
The new build system doesn't need the makefile.dependencies, and that has always been a bit of a mystery.
.hc
On Tue, Nov 29, 2011 at 5:37 PM, Hans-Christoph Steiner hans@at.or.at wrote:
The new build system doesn't need the makefile.dependencies, and that has always been a bit of a mystery.
Ah, so I'm not the only one being puzzled, happy you say so. I'm intensely frustrated after spending five days to get things working with mingw. Todays it's like this: when compiling pd-double with makefile.mingw, makefile.dependencies does actually get produced, but then comes 'no rule to make am--refresh. Stop.' when entering extra/. No clue how to solve that again. Writing or fixing C code is easy pie compared to handling the GNU build tools. It is a miracle how you guys manage to produce all those pd-extended builds. Well I should probably read the f. manual, it's too complex to hack ur way through it. Another pit stop on the way to pd-double.
Katja
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-11-29 18:29, katja wrote:
On Tue, Nov 29, 2011 at 5:37 PM, Hans-Christoph Steiner hans@at.or.at wrote:
The new build system doesn't need the makefile.dependencies, and that has always been a bit of a mystery.
Ah, so I'm not the only one being puzzled, happy you say so. I'm intensely frustrated after spending five days to get things working with mingw. Todays it's like this: when compiling pd-double with makefile.mingw, makefile.dependencies does actually get produced, but then comes 'no rule to make am--refresh. Stop.' when entering extra/.
you shall decide to either use makefile.mingw or the new autotools system. you shall never mix the two. especially, you shall not run ./autogen.sh and then try to compile using makefile.mingw
thus: remove all traces from the autotools build system (namely any generated files, like GNUmakefile)
mfgasdr IOhannes
On Tue, Nov 29, 2011 at 7:02 PM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
you shall decide to either use makefile.mingw or the new autotools system. you shall never mix the two. especially, you shall not run ./autogen.sh and then try to compile using makefile.mingw
thus: remove all traces from the autotools build system (namely any generated files, like GNUmakefile)
Ha. That is a decisive remark. So the generated makefiles were confusing the process from makefile.mingw. Back-and-forth jumping between the methods probably induced some irreproducible successes as well.
Now starting with two fresh copies of the sources, one for each build system. Still an error with makefile.mingw, (no rule to make the 'extra's') but that should be solvable.
Katja
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
katja -
Martin Peach -
Menno van der Woude -
Miller Puckette -
Patrice Colet