The Mac OS X 10.3 build is still dying here. There hasn't been a 10.3 fix for many weeks. Could this be fixed? It could be done with an #ifdef for Mac OS X 10.3 alone, at the very least. Then we'd have Pd-extended builds on 10.3 again.
g++ -c -g -O2 -fPIC -freg-struct-return -Os -falign-loops=32 -falign- functions=32 -falign-jumps=32 -funroll-loops -ffast-math -faltivec - fpascal-strings -I.. -I/Users/pd/auto-build/pd-extended/pd/src GemPixImageLoad.cpp -o GemPixImageLoad.o GemPixConvertAltivec.cpp: In function `void YUV422_to_BGRA_altivec (unsigned char*, long unsigned int, unsigned char*)': GemPixConvertAltivec.cpp:753: error: cannot convert `vector int' to `vector unsigned int' in assignment GemPixConvertAltivec.cpp:754: error: cannot convert `vector int' to `vector unsigned int' in assignment GemPixConvertAltivec.cpp:755: error: no instance of overloaded builtin function `vec_sub' matches the parameter list GemPixConvertAltivec.cpp:756: error: no instance of overloaded builtin function `vec_sub' matches the parameter list GemPixConvertAltivec.cpp:761: error: cannot convert `vector int' to `vector unsigned int' in assignment GemPixConvertAltivec.cpp:762: error: cannot convert `vector int' to `vector unsigned int' in assignment GemPixConvertAltivec.cpp:764: error: cannot convert `vector int' to `vector unsigned int' in assignment GemPixConvertAltivec.cpp:765: error: cannot convert `vector int' to `vector unsigned int' in assignment GemPixConvertAltivec.cpp:772: error: cannot convert `vector int' to `vector unsigned int' in assignment GemPixConvertAltivec.cpp:773: error: cannot convert `vector int' to `vector unsigned int' in assignment GemPixConvertAltivec.cpp:781: error: no instance of overloaded builtin function `vec_add' matches the parameter list GemPixConvertAltivec.cpp:782: error: no instance of overloaded builtin function `vec_add' matches the parameter list GemPixConvertAltivec.cpp:783: error: no instance of overloaded builtin function `vec_add' matches the parameter list GemPixConvertAltivec.cpp:784: error: no instance of overloaded builtin function `vec_add' matches the parameter list GemPixConvertAltivec.cpp:785: error: no instance of overloaded builtin function `vec_add' matches the parameter list GemPixConvertAltivec.cpp:786: error: no instance of overloaded builtin function `vec_add' matches the parameter list GemPixConvertAltivec.cpp:797: error: cannot convert `vector short unsigned int' to `vector short int' in assignment GemPixConvertAltivec.cpp:798: error: cannot convert `vector short unsigned int' to `vector short int' in assignment GemPixConvertAltivec.cpp:799: error: cannot convert `vector short unsigned int' to `vector short int' in assignment make[3]: *** [GemPixConvertAltivec.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [Base] Error 2 make[1]: *** [/Users/pd/auto-build/pd-extended/Gem/src/Gem.pd_darwin] Error 2 make: *** [extended_install] Error 2
.hc
------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
On Nov 13, 2006, at 9:46 AM, Hans-Christoph Steiner wrote:
The Mac OS X 10.3 build is still dying here. There hasn't been a 10.3 fix for many weeks. Could this be fixed? It could be done with an #ifdef for Mac OS X 10.3 alone, at the very least. Then we'd have Pd-extended builds on 10.3 again.
...is this being built with gcc 3.3 or 4.01? I'm wondering if there'd be a difference between the way the headers are overloaded...other than that, I just ran out of ideas, so I'll try to look at it again...
jamie
On Nov 13, 2006, at 10:52 AM, james tittle wrote:
On Nov 13, 2006, at 9:46 AM, Hans-Christoph Steiner wrote:
The Mac OS X 10.3 build is still dying here. There hasn't been a 10.3 fix for many weeks. Could this be fixed? It could be done with an #ifdef for Mac OS X 10.3 alone, at the very least. Then we'd have Pd-extended builds on 10.3 again.
...is this being built with gcc 3.3 or 4.01? I'm wondering if there'd be a difference between the way the headers are overloaded...other than that, I just ran out of ideas, so I'll try to look at it again...
Its a plain 10.3 install, so 3.3:
pd@macosx103-powerpc:~ > gcc --version gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1671) Copyright (C) 2002 Free Software Foundation, Inc.
.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
Hans-Christoph Steiner wrote:
The Mac OS X 10.3 build is still dying here. There hasn't been a 10.3 fix for many weeks. Could this be fixed? It could be done with an #ifdef for Mac OS X 10.3 alone, at the very least. Then we'd have Pd-extended builds on 10.3 again.
so i have made the code conditional ("#ifdef __GNUC__ < 4")
apart from that, wouldn't it be a good idea, to have the nightly builds be a bit more tolerant to build-failures? e.g. compile the submodules (libraries) with the "-k" flag; this would allow to have nightly builds with the libraries missing, that failed to install (but nevertheless there would be a nightly build)
mfg.adr IOhannes
On Nov 13, 2006, at 11:11 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
The Mac OS X 10.3 build is still dying here. There hasn't been a 10.3 fix for many weeks. Could this be fixed? It could be done with an #ifdef for Mac OS X 10.3 alone, at the very least. Then we'd have Pd-extended builds on 10.3 again.
so i have made the code conditional ("#ifdef __GNUC__ < 4")
apart from that, wouldn't it be a good idea, to have the nightly builds be a bit more tolerant to build-failures? e.g. compile the submodules (libraries) with the "-k" flag; this would allow to have nightly builds with the libraries missing, that failed to install (but nevertheless there would be a nightly build)
Yes, it should work a lot better, but that takes more work that just make -k unfortunately. I don't think setting the auto-build scripts to use make -k would be a good idea because then it would be quite hard to find the errors.
Instead, I think we should setup BuiltBot:
http://buildbot.sourceforge.net/
That will take quite a bit of work, but I think would be very useful. It will try building everything on a schedule, plus it'll build anything that was just checked into CVS, then email the person who made that checkin if there was an error.
But that will also take a lot of work on the Pd build system to make it work like that.
.hc
------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
Hans-Christoph Steiner wrote:
The Mac OS X 10.3 build is still dying here. There hasn't been a 10.3 fix for many weeks. Could this be fixed? It could be done with an #ifdef for Mac OS X 10.3 alone, at the very least. Then we'd have Pd-extended builds on 10.3 again.
i was already wondering.... every day i see the build log and think to myself "this oughta be fixed".
fixes and workarounds include: + real fixes, which use the correct types when calling the intrinsic functions (needs to be tested by someone who does not work via ssh...) + add tests to configure whether the compiler accepts unsigned vs signed vectors in the intrinsics and conditionally disable the problematic code. + #ifdef the code for given compilers (gcc-versions) + #ifdef the code for given platforms (osx-10.3) + disable the use of altivec in the osx-10.3 builds via configure-args + disable the use of altivec on osX via configure-args
imo, the simplest solution would be to disable altivec via configure, but i doubt that you would like this (and i understand this). most likely it is not really possible to have different configure-flags for 10.3 and 10.4 builds in the build-system (read: it would mean much work for little gain).
i don't like the idea of disabling the code via an "#ifdef OSX10.3" at all, since it is not osx-10.3 that prevents Gem from building but the compiler.
adding a test to configure needs more time than i currently have.
this basically gives us 3 possible solutions: + fix the code + #ifdef the compiler-version + disable altivec in the pd-extended versions
unless somebody does a real fix, i will try the 2nd solution (at the risk of disabling more than would be needed)
mfg.,adsr IOhannes
PS: damned, i forgot to send this earlier...
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
james tittle