Patches item #3065532, was opened at 2010-09-13 22:46 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3065532...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update.
Category: puredata Group: None
Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette)
Summary: [bugfix] autotools on MinGW/MSYS
Initial Comment: On Windows XP with MinGW in the MSYS shell, using the latest HEAD in pure-data.git, running ./autogen.sh && ./configure causes this error:
./autogen.sh && ./configure && make libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `m4/config'. libtoolize: linking file `m4/config/config.guess' libtoolize: linking file `m4/config/config.sub' libtoolize: linking file `m4/config/install-sh' libtoolize: linking file `m4/config/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4/generated'. libtoolize: linking file `m4/generated/libtool.m4' libtoolize: linking file `m4/generated/ltoptions.m4' libtoolize: linking file `m4/generated/ltsugar.m4' libtoolize: linking file `m4/generated/ltversion.m4' libtoolize: linking file `m4/generated/lt~obsolete.m4' checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 ./configure: line 2551: syntax error near unexpected token `IPHONEOS=yes,' ./configure: line 2551: `PD_CHECK_IPHONE(IPHONEOS=yes, IPHONEOS=no, { { echo "$as_me:$LINENO: error: iPhoneOS SDK not available" >&5'
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-09-14 11:28
Message: i see the problem, but fail to understand why the "&&" chaining does not stop the entire build. i guess that the call to aclocal fails, but why autogen.sh then returns TRUE is beyond my understanding.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3065532...
On 2010-09-14 11:30, SourceForge.net wrote:
Message: i see the problem, but fail to understand why the "&&" chaining does not stop the entire build. i guess that the call to aclocal fails, but why autogen.sh then returns TRUE is beyond my understanding.
it seems like i cannot log into the PdLab w32 machine via rdesktop (ssh access works fine, but this gives me a cygwin environment and not the mingw/msys needed to reproduce the problem.
i believe the patch i attached to the ticket to solve the problem but have not been able to test on the very platform.
ghasdf IOhannes
On Sep 14, 2010, at 5:34 AM, IOhannes m zmoelnig wrote:
On 2010-09-14 11:30, SourceForge.net wrote:
Message: i see the problem, but fail to understand why the "&&" chaining does not stop the entire build. i guess that the call to aclocal fails, but why autogen.sh then returns TRUE is beyond my understanding.
it seems like i cannot log into the PdLab w32 machine via rdesktop (ssh access works fine, but this gives me a cygwin environment and not the mingw/msys needed to reproduce the problem.
i believe the patch i attached to the ticket to solve the problem but have not been able to test on the very platform.
I just connected via rdesktop last night, double-check the instructions, you can't go directly, you have to use an ssh tunnel:
http://puredata.info/docs/developer/WindowsXPI386
.hc
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On 2010-09-14 17:42, Hans-Christoph Steiner wrote:
i believe the patch i attached to the ticket to solve the problem but have not been able to test on the very platform.
ok, i managed to log in, and my patch indeed solves the reported problem.
however, there are more issues, coming from parts of the new build system which i never touched. so i would like to discuss them, before i remove them:
#1 when building with msys, the new build system includes pd-watchdog unfortunately, the watchdog uses signals and other quite linux specific stuff. i don't know whether this can be ported, and whether this actually make sense.
conclusion: i would exclude pd-watchdog from all w32 builds (if people need signals and whatnot, why don't they use an os that has signals and whatnot)
#2 when building with msys, the compiler is forced to "g++". there are several problems with this: -- the user cannot chose the compiler themselves anymore, as the CC variable is silently ignored and reset to "g++" -- no check is done whether there actually is an executable named "g++", it is just assumed. this kind of leads autoconf ad absurdum, as we can simply check for a valid c++ compiler if needed.
-- most important however: compiling Pd with a c++ compiler can be a bad idea! the Pd source uses C++ keywords (e.g. "template" is often used). throwing this code onto a c++ compiler leads to errors.
conclusion: don't force autoconf to use g++ as the c-compiler, but rather let it choose the right compiler automagically
if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner.
masdrt IOhannes
On Sep 15, 2010, at 6:02 AM, IOhannes m zmoelnig wrote:
On 2010-09-14 17:42, Hans-Christoph Steiner wrote:
i believe the patch i attached to the ticket to solve the problem but have not been able to test on the very platform.
ok, i managed to log in, and my patch indeed solves the reported problem.
however, there are more issues, coming from parts of the new build system which i never touched. so i would like to discuss them, before i remove them:
#1 when building with msys, the new build system includes pd-watchdog unfortunately, the watchdog uses signals and other quite linux specific stuff. i don't know whether this can be ported, and whether this actually make sense.
conclusion: i would exclude pd-watchdog from all w32 builds (if people need signals and whatnot, why don't they use an os that has signals and whatnot)
I am pretty sure that Cygwin has signals, so pd-watchdog should just be removed for MinGW/Windows builds.
#2 when building with msys, the compiler is forced to "g++". there are several problems with this: -- the user cannot chose the compiler themselves anymore, as the CC variable is silently ignored and reset to "g++" -- no check is done whether there actually is an executable named "g+ +", it is just assumed. this kind of leads autoconf ad absurdum, as we can simply check for a valid c++ compiler if needed.
-- most important however: compiling Pd with a c++ compiler can be a bad idea! the Pd source uses C++ keywords (e.g. "template" is often used). throwing this code onto a c++ compiler leads to errors.
conclusion: don't force autoconf to use g++ as the c-compiler, but rather let it choose the right compiler automagically
if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner.
Try building with the ASIO sources, which are C++ and need to be built with g++. gcc won't link C++ code into a C binary from what I could tell. So at least the final linking needs to be done with g++. In makefile.mingw, all C is built with gcc and all C++ is built with g++, then the whole thing is linked with g++.
.hc
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On 2010-09-15 15:20, Hans-Christoph Steiner wrote:
if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner.
Try building with the ASIO sources, which are C++ and need to be built
i have to admit that i am unable to get that properly setup on the PdLab machine (no time for such things).
if i could get a copy of everything needed for building (really no time for installing things on an os which i don't like; it's ok for just fixing bugs :-) i know somebody has to do that work and i hate to delegate it to e.g. you, but i think this is really a matter of efficiency), i will try.
with g++. gcc won't link C++ code into a C binary from what I could tell. So at least the final linking needs to be done with g++. In
that's what i was saying above: "if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler)"
makefile.mingw, all C is built with gcc and all C++ is built with g++, then the whole thing is linked with g++.
that's how it is supposed to be. afaik, automake provides easy ways for that...
fgmasdr IOhannes
On 2010-09-15 15:56, IOhannes m zmoelnig wrote:
On 2010-09-15 15:20, Hans-Christoph Steiner wrote:
if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner.
Try building with the ASIO sources, which are C++ and need to be built
the current state of affairs can be found in my puredata repository at github (branch:3065532)
http://github.com/umlaeute/pd-vanilla/tree/3065532
Pd mostly compiles on msys/mingw now (with the noteable exception of pd~, which has to be excluded on w32)
automake now also produces a pd.def file for the exports (though there is still no pd.dll, since this is statically compiled into pd.exe)
fgmasdf IOhannes
On Wed, 2010-09-15 at 20:56 +0200, IOhannes m zmoelnig wrote:
On 2010-09-15 15:56, IOhannes m zmoelnig wrote:
On 2010-09-15 15:20, Hans-Christoph Steiner wrote:
if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner.
Try building with the ASIO sources, which are C++ and need to be built
the current state of affairs can be found in my puredata repository at github (branch:3065532)
http://github.com/umlaeute/pd-vanilla/tree/3065532
Pd mostly compiles on msys/mingw now (with the noteable exception of pd~, which has to be excluded on w32)
automake now also produces a pd.def file for the exports (though there is still no pd.dll, since this is statically compiled into pd.exe)
Sounds good! Thanks for sharing the pain of Windows! It'll be great once we can ditch the makefile.mingw once and for all.
.hc
On Sep 15, 2010, at 2:56 PM, IOhannes m zmoelnig wrote:
On 2010-09-15 15:56, IOhannes m zmoelnig wrote:
On 2010-09-15 15:20, Hans-Christoph Steiner wrote:
if we need a c++-aware linker, then we should ask for a c++-aware linker (rather than force a c++ compiler). afaik, automake can handle this with a 1-liner.
Try building with the ASIO sources, which are C++ and need to be built
the current state of affairs can be found in my puredata repository at github (branch:3065532)
http://github.com/umlaeute/pd-vanilla/tree/3065532
Pd mostly compiles on msys/mingw now (with the noteable exception of pd~, which has to be excluded on w32)
automake now also produces a pd.def file for the exports (though there is still no pd.dll, since this is statically compiled into pd.exe)
Getting close to a unified build system! If you what, I'll create a buildbot build from your git, but it'll only build from master. Let me know which git URL, and I'll set it up in buildbot.
.hc
----------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
SourceForge.net