I switched the Pd-extended build system to use the Gem build system directly for everything, including 'make install' and Windows/MinGW. I just fixed one small MinGW build bug, and am now installing Quicktime 7.3 SDK on the Windows build machine.
Hopefully, its just a matter of pointing the build system to the location of the QuickTime SDK. I installed it into the default location of "%ProgramFiles%\Quicktime SDK".
.hc
----------------------------------------------------------------------------
I'm stuck at:
In file included from C:/Program Files/QuickTime SDK/CIncludes/ CoreServices.h:78, from C:/Program Files/QuickTime SDK/CIncludes/ HIObject.h:20, from C:/Program Files/QuickTime SDK/CIncludes/ Menus.h:68, from C:/Program Files/QuickTime SDK/CIncludes/ MacWindows.h:72, from C:/Program Files/QuickTime SDK/CIncludes/QTML.h: 28, from GemMan.h:29, from GemContext.cpp:16: C:/Program Files/QuickTime SDK/CIncludes/Math64.h:86:64: invalid suffix "i64" on integer constant
This is the answer if you can modify the troublesome sources: http://lists-archives.org/mingw-users/07335-i64-and-ui64-suffix-not-recogniz... But this is from a Quicktime header, so we should probably find a different solution.
.hc
On Jul 16, 2011, at 5:28 PM, Hans-Christoph Steiner wrote:
I switched the Pd-extended build system to use the Gem build system directly for everything, including 'make install' and Windows/ MinGW. I just fixed one small MinGW build bug, and am now installing Quicktime 7.3 SDK on the Windows build machine.
Hopefully, its just a matter of pointing the build system to the location of the QuickTime SDK. I installed it into the default location of "%ProgramFiles%\Quicktime SDK".
.hc
http://at.or.at/hans/
----------------------------------------------------------------------------
One last thought: this particular issue might be fixed by the MinGW64 toolchain. Anyone have that running and want to try to build this? Is patko on this list?
.hc
On Jul 16, 2011, at 6:04 PM, Hans-Christoph Steiner wrote:
I'm stuck at:
In file included from C:/Program Files/QuickTime SDK/CIncludes/ CoreServices.h:78, from C:/Program Files/QuickTime SDK/CIncludes/ HIObject.h:20, from C:/Program Files/QuickTime SDK/CIncludes/ Menus.h:68, from C:/Program Files/QuickTime SDK/CIncludes/ MacWindows.h:72, from C:/Program Files/QuickTime SDK/CIncludes/QTML.h: 28, from GemMan.h:29, from GemContext.cpp:16: C:/Program Files/QuickTime SDK/CIncludes/Math64.h:86:64: invalid suffix "i64" on integer constant
This is the answer if you can modify the troublesome sources: http://lists-archives.org/mingw-users/07335-i64-and-ui64-suffix-not-recogniz... But this is from a Quicktime header, so we should probably find a different solution.
.hc
On Jul 16, 2011, at 5:28 PM, Hans-Christoph Steiner wrote:
I switched the Pd-extended build system to use the Gem build system directly for everything, including 'make install' and Windows/ MinGW. I just fixed one small MinGW build bug, and am now installing Quicktime 7.3 SDK on the Windows build machine.
Hopefully, its just a matter of pointing the build system to the location of the QuickTime SDK. I installed it into the default location of "%ProgramFiles%\Quicktime SDK".
.hc
http://at.or.at/hans/
http://at.or.at/hans/
----------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-17 00:09, Hans-Christoph Steiner wrote:
One last thought: this particular issue might be fixed by the MinGW64 toolchain. Anyone have that running and want to try to build this? Is patko on this list?
But this is from a Quicktime header, so we should probably find a different solution.
if the MinGW64 toolchain does not fix it, i guess the simplest would be to DO modify the upstream code. a quick grep over the CIncludes reveals that there are two (2) occurences of the "(u)i64" suffix in all (relevant) CIncludes/ of the QT-SDK.
fgmasdr IOhannes
On Jul 18, 2011, at 4:45 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-17 00:09, Hans-Christoph Steiner wrote:
One last thought: this particular issue might be fixed by the MinGW64 toolchain. Anyone have that running and want to try to build this? Is patko on this list?
But this is from a Quicktime header, so we should probably find a different solution.
if the MinGW64 toolchain does not fix it, i guess the simplest would be to DO modify the upstream code. a quick grep over the CIncludes reveals that there are two (2) occurences of the "(u)i64" suffix in all (relevant) CIncludes/ of the QT-SDK.
I'm up for doing that as a temporary fix. My guess is the real fix will be using the MinGW64 toolchain... too bad there is no package management for that.
In the meantime, it seems that the MinGW build is dying on something different, which is not making sense to me:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src - DHAVE_VERSION_H -DPD -I/home/pd/auto-build/pd-extended/pd/src - DHAVE_S_STUFF_H -O2 -mcpu=i586 -mtune=pentium3 -freg-struct-return -O3 -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast- math -msse2 -MT libGem_la-Dylib.lo -MD -MP -MF .deps/libGem_la- Dylib.Tpo -c Dylib.cpp -DDLL_EXPORT -DPIC -o .libs/libGem_la-Dylib.o Dylib.cpp: In member function `void* GemDylib::proc(std::string)': Dylib.cpp:104: error: ISO C++ forbids casting between pointer-to- function and pointer-to-object Dylib.cpp: In member function `bool GemDylib::run(std::string)': Dylib.cpp:113: error: ISO C++ forbids casting between pointer-to- function and pointer-to-object
.hc
----------------------------------------------------------------------------
kill your television
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/21/2011 10:31 PM, Hans-Christoph Steiner wrote:
I'm up for doing that as a temporary fix. My guess is the real fix will be using the MinGW64 toolchain... too bad there is no package management for that.
definitely.
In the meantime, it seems that the MinGW build is dying on something different, which is not making sense to me:
Dylib.cpp:104: error: ISO C++ forbids casting between pointer-to-function and pointer-to-object Dylib.cpp: In member function `bool GemDylib::run(std::string)': Dylib.cpp:113: error: ISO C++ forbids casting between pointer-to-function and pointer-to-object
obivously, the compiler thinks that "void*" is a pointer to an object, and it knows that we need a pointer to a function, and ISO C++ forbids the conversion between the two... weird, it doesn't happen anywhere else (and i'm not sure that they are right in saying that (void*) is indeed a pointer to an object...)
anyhow, i hope i fixed it with rev4361
fgmasr IOhannes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-16 23:28, Hans-Christoph Steiner wrote:
I switched the Pd-extended build system to use the Gem build system directly for everything, including 'make install' and Windows/MinGW. I just fixed one small MinGW build bug, and am now installing Quicktime 7.3 SDK on the Windows build machine.
great.
however, i don't understand your "tweaked configure flags for Gem on MinGW" commit that does: <snip> + --disable-mmx \ + --enable-sse2 \ </snip>
why would you want to disable "MMX" if you are enabling "SSE2"?
fgmasdr IOhannes
On Jul 18, 2011, at 4:17 AM, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-07-16 23:28, Hans-Christoph Steiner wrote:
I switched the Pd-extended build system to use the Gem build system directly for everything, including 'make install' and Windows/ MinGW. I just fixed one small MinGW build bug, and am now installing Quicktime 7.3 SDK on the Windows build machine.
great.
however, i don't understand your "tweaked configure flags for Gem on MinGW" commit that does:
<snip> + --disable-mmx \ + --enable-sse2 \ </snip>
why would you want to disable "MMX" if you are enabling "SSE2"?
I was under the impression that SSE2 replaces MMX, and that if you're using SSE2, you should not use MMX at all. But I could be wrong. If anyone knows better than me, please adjust accordingly.
.hc
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/21/2011 10:29 PM, Hans-Christoph Steiner wrote:
however, i don't understand your "tweaked configure flags for Gem on MinGW" commit that does:
<snip> + --disable-mmx \ + --enable-sse2 \ </snip>
why would you want to disable "MMX" if you are enabling "SSE2"?
I was under the impression that SSE2 replaces MMX, and that if you're using SSE2, you should not use MMX at all. But I could be wrong. If anyone knows better than me, please adjust accordingly.
SSE2 is just an aditional instruction set that targets the same problem: SIMD;
virtually any CPU that supports SSE2 will _also_ support MMX (i don't know/think whether this is required though)
they are not mutually exclusive at all. e.g. Gem has a number of SIMD optimized functions that use MMX, and a few that are optimized using SSE2;
which means that enabling SSE2 and disabling MMX would in generally result in poorer performance.
luckily things don't work that way, because as soon as you turn on SSE2 optimization, you are also turrning on MMX optimization, so in this specific case you still get both (the only thing "--disable-mmx" flag does here, is to prevent the "-mmmx" flag to be added to the CFLAGS; the "-msse2" flag (added by --enable-sse2) will automatically turn on MMX as well)
so adding "--disable-mmx" does no real harm, but adds confusion, as it pretends to turn a feature off, which in reality is still enabled.
fgmasdr IOhannes
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig