I got the 10.4/i386 build server going, and I see this:
g++ -c -I/sw/include -I/sw/include/freetype2 -I.. -I/usr/ include/FTGL -I/usr/include/freetype2 -I/Users/pd/auto-build/pd-devel/ pd/src -DHAVE_CONFIG_H -I/sw/include -I/sw/include/FTGL -g -O2 -fPIC - freg-struct-return -Os -falign-loops=32 -falign-functions=32 -falign- jumps=32 -funroll-loops -ffast-math -mmmx -fpascal-strings GemPBuffer.cpp -o ../Objects/GemPBuffer.oGemPBuffer.cpp: In constructor 'PBuffer::PBuffer(int, int, int)': GemPBuffer.cpp:269: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:269: error: initializing argument 2 of 'CGLError CGLGetVirtualScreen(_CGLContextObject*, long int*)'GemPBuffer.cpp:271: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:271: error: initializing argument 3 of 'CGLError CGLChoosePixelFormat(const CGLPixelFormatAttribute*, _CGLPixelFormatObject**, long int*)' GemPBuffer.cpp:282: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:282: error: initializing argument 2 of 'CGLError CGLGetVirtualScreen(_CGLContextObject*, long int*)' GemPBuffer.cpp: In member function 'void PBuffer::enable()': GemPBuffer.cpp:306: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:306: error: initializing argument 2 of 'CGLError CGLGetVirtualScreen(_CGLContextObject*, long int*)'
If you need to test which version of gcc is in use, you can use what I have for FTGL:
#if defined(__APPLE_CC__) && __APPLE_CC__<5400
.hc
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
I got the 10.4/i386 build server going, and I see this:
[...]
which version?
i seem to remember having seen this bug (either on list or in real live) and i also seem to remember having fixed it.
fgmasr IOhannes
If you mean Gem, its what's in the Pd-extended builds, isn't that the 0.92 branch? You can login into that machine if you need to, its a proper part of the PdLab machines:
http://puredata.info/docs/developer/Macosx104I386
.hc
On Nov 20, 2009, at 4:59 AM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
I got the 10.4/i386 build server going, and I see this:
[...]
which version?
i seem to remember having seen this bug (either on list or in real live) and i also seem to remember having fixed it.
fgmasr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksGaIYACgkQkX2Xpv6ydvThWQCgmYYKJivS0OnL5FzCo3TswXuG OQ4AoNXG+0GFpIU0uKCJAttuDmgLgKYl =hSTJ -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
"Making boring techno music is really easy with modern tools," he says, "but with live coding, boring techno is much harder." - Chris McCormick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hans-Christoph Steiner wrote:
If you mean Gem, its what's in the Pd-extended builds, isn't that the 0.92 branch?
don't know. i don't think _i_ have changed anything here. i thought PdX-trunk would use Gem-trunk whereas PdX-0.42 would use Gem-0.92.
You can login into that machine if you need to, its a proper part of the PdLab machines:
i'd like to but my key is not installed on that machine.
fmasdr5 IOhannes
Hans-Christoph Steiner wrote:
If you need to test which version of gcc is in use, you can use what I have for FTGL:
#if defined(__APPLE_CC__) && __APPLE_CC__<5400
i don't understang the relation to FTGL. are you talking about the fink package "ftgl"?
does Gem have any problems with FTGL on 10.4?
fgadrm IOhannes
On Nov 24, 2009, at 9:15 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
If you need to test which version of gcc is in use, you can use what I have for FTGL:
#if defined(__APPLE_CC__) && __APPLE_CC__<5400
i don't understang the relation to FTGL. are you talking about the fink package "ftgl"?
does Gem have any problems with FTGL on 10.4?
Yes, the software FTGL which is packaged as libftgl1 in Fink. I remember a similar error when using one version of the compiler and not the other. Fixing it for one version of the compiler broke it for the other version of the compiler, hence that #if defined...
.hc
----------------------------------------------------------------------------
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
Hans-Christoph Steiner wrote:
I got the 10.4/i386 build server going, and I see this:
g++ -c -I/sw/include -I/sw/include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/freetype2 -I/Users/pd/auto-build/pd-devel/pd/src -DHAVE_CONFIG_H -I/sw/include -I/sw/include/FTGL -g -O2 -fPIC -freg-struct-return -Os -falign-loops=32 -falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math -mmmx -fpascal-strings GemPBuffer.cpp -o ../Objects/GemPBuffer.oGemPBuffer.cpp: In constructor 'PBuffer::PBuffer(int, int, int)': GemPBuffer.cpp:269: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:269: error: initializing argument 2 of 'CGLError CGLGetVirtualScreen(_CGLContextObject*, long int*)'GemPBuffer.cpp:271: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:271: error: initializing argument 3 of 'CGLError CGLChoosePixelFormat(const CGLPixelFormatAttribute*, _CGLPixelFormatObject**, long int*)' GemPBuffer.cpp:282: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:282: error: initializing argument 2 of 'CGLError CGLGetVirtualScreen(_CGLContextObject*, long int*)' GemPBuffer.cpp: In member function 'void PBuffer::enable()': GemPBuffer.cpp:306: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:306: error: initializing argument 2 of 'CGLError CGLGetVirtualScreen(_CGLContextObject*, long int*)'
If you need to test which version of gcc is in use,
no, the problem is not the compiler. it's the headers that are used.
according to the documentation of CGL and according to the header-files (on a 10.5 machine), the definition of the function is:
"CGLGetVirtualScreen(CGLContextObj ctx, GLint *screen)" and not "long int*"
(quoting my other email from beginning of november).
the header file (/System/Library/Frameworks/OpenGL.framework/Headers/OpenGL.h) on the build-machine has: extern CGLError CGLGetVirtualScreen(CGLContextObj ctx, long *screen);
i _strongly_ believe that you have installed the wrong headers. if you could show me _any_ "official" ressource that uses "long" i might be convinced.
in the meantime i have added some hackz to the Gem code that should make it compile again.
the svn client installed on the build-machine (/sw/bin/svn) is somewhat outdated (1.4.4) and refuses to "svn update" the sandbox.
fgmasdr IOhannes
On Nov 24, 2009, at 9:26 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I got the 10.4/i386 build server going, and I see this:
g++ -c -I/sw/include -I/sw/include/freetype2 -I.. -I/usr/include/FTGL -I/usr/include/freetype2 -I/Users/pd/auto-build/pd-devel/pd/src -DHAVE_CONFIG_H -I/sw/include -I/sw/include/FTGL -g -O2 -fPIC -freg-struct-return -Os -falign- loops=32 -falign-functions=32 -falign-jumps=32 -funroll-loops -ffast-math - mmmx -fpascal-strings GemPBuffer.cpp -o ../Objects/GemPBuffer.oGemPBuffer.cpp: In constructor 'PBuffer::PBuffer(int, int, int)': GemPBuffer.cpp:269: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:269: error: initializing argument 2 of 'CGLError CGLGetVirtualScreen(_CGLContextObject*, long int*)'GemPBuffer.cpp: 271: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:271: error: initializing argument 3 of 'CGLError CGLChoosePixelFormat(const CGLPixelFormatAttribute*, _CGLPixelFormatObject**, long int*)' GemPBuffer.cpp:282: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:282: error: initializing argument 2 of 'CGLError CGLGetVirtualScreen(_CGLContextObject*, long int*)' GemPBuffer.cpp: In member function 'void PBuffer::enable()': GemPBuffer.cpp:306: error: invalid conversion from 'GLint*' to 'long int*' GemPBuffer.cpp:306: error: initializing argument 2 of 'CGLError CGLGetVirtualScreen(_CGLContextObject*, long int*)'
If you need to test which version of gcc is in use,
no, the problem is not the compiler. it's the headers that are used.
according to the documentation of CGL and according to the header- files (on a 10.5 machine), the definition of the function is:
"CGLGetVirtualScreen(CGLContextObj ctx, GLint *screen)" and not "long int*"
(quoting my other email from beginning of november).
the header file (/System/Library/Frameworks/OpenGL.framework/Headers/OpenGL.h) on the build-machine has: extern CGLError CGLGetVirtualScreen(CGLContextObj ctx, long *screen);
i _strongly_ believe that you have installed the wrong headers. if you could show me _any_ "official" ressource that uses "long" i might be convinced.
in the meantime i have added some hackz to the Gem code that should make it compile again.
the svn client installed on the build-machine (/sw/bin/svn) is somewhat outdated (1.4.4) and refuses to "svn update" the sandbox.
I definitely did not change the headers, and since they are in /System/ Library, that means no package installs, that's only for stuff that comes from Apple. Whether they are 'wrong' or not is then a question for Apple. And we mostly likely have to deal with a workaround :) Sounds like Apple fixed this in 10.5...
and that's where the compiler text comes in. If you are building on 10.4, you'll be bulding with an older version of gcc. 10.5 has a newer version. The easiest way to test that is to test for that build number that I quoted you before.
.hc
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
I definitely did not change the headers, and since they are in /System/Library, that means no package installs, that's only for stuff that comes from Apple. Whether they are 'wrong' or not is then a question for Apple. And we mostly likely have to deal with a workaround :) Sounds like Apple fixed this in 10.5...
probably. it's only weird that i have found zero documentation about this. everything i find would be in accordance to how it was handled in Gem (and which failed on the build machine).
anyhow,....
and that's where the compiler text comes in. If you are building on 10.4, you'll be bulding with an older version of gcc. 10.5 has a newer version. The easiest way to test that is to test for that build number that I quoted you before.
oh no. i plainly refuse to relate the problems of some header revision to the version of gcc. the compiler you are using is the compiler you have installed, not the one on the DVD you bought to install your operatingsystem.
your test is a good one if you want to test whether you can use a specific extension of the compiler (e.g. your favourite pragma). it's a really bad one to test for the capabilities of a library. e.g. we don't use __APPLE_CC__ to detect whether the target system is running OSX (just like we don't use __GNUC__ to detect whether the target system is linux. we also don't use the __APPLE_CC__ version number to test which architecture the target has (e.g. because older versions of OSX only ran on ppc whereas the latest and greatest only runs on little endian archs)
i guess you get what i want to say :-)
fgmasdr IOhannes
PS: the crucial part of my email started with "in the meantime".
On Nov 25, 2009, at 12:36 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I definitely did not change the headers, and since they are in /System/Library, that means no package installs, that's only for stuff that comes from Apple. Whether they are 'wrong' or not is then a question for Apple. And we mostly likely have to deal with a workaround :) Sounds like Apple fixed this in 10.5...
probably. it's only weird that i have found zero documentation about this. everything i find would be in accordance to how it was handled in Gem (and which failed on the build machine).
anyhow,....
and that's where the compiler text comes in. If you are building on 10.4, you'll be bulding with an older version of gcc. 10.5 has a newer version. The easiest way to test that is to test for that build number that I quoted you before.
oh no. i plainly refuse to relate the problems of some header revision to the version of gcc. the compiler you are using is the compiler you have installed, not the one on the DVD you bought to install your operatingsystem.
your test is a good one if you want to test whether you can use a specific extension of the compiler (e.g. your favourite pragma). it's a really bad one to test for the capabilities of a library. e.g. we don't use __APPLE_CC__ to detect whether the target system is running OSX (just like we don't use __GNUC__ to detect whether the target system is linux. we also don't use the __APPLE_CC__ version number to test which architecture the target has (e.g. because older versions of OSX only ran on ppc whereas the latest and greatest only runs on little endian archs)
i guess you get what i want to say :-)
fgmasdr IOhannes
PS: the crucial part of my email started with "in the meantime".
All I am saying is that this is a technique used for a bunch of code. I think that newer versions of gcc do stricter testing, that's why its relevant.
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Hans-Christoph Steiner wrote:
All I am saying is that this is a technique used for a bunch of code. I think that newer versions of gcc do stricter testing, that's why its relevant.
all i'm saying is that one should not test for one thing in order to get properties of another thing.
your argument is, that the compiler has changed and now refuses (or: refused then) to compile. if this was for good reason, then the code should be fixed (in our case: to use the correct types). if it was for no good reasons, one could try to circumvent the compiler (by taking hand-tailored measures)
anyhow, the problem is not the compiler. it is the header files. thus the problem should not fixed for the compiler but for the headers.
i guess any compiler since OSX-10.2 would probably bail out at the very same spot (and for good reasons).
could you try whether it works.
fgmasdr IOhannes
On Nov 25, 2009, at 2:11 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
All I am saying is that this is a technique used for a bunch of code. I think that newer versions of gcc do stricter testing, that's why its relevant.
all i'm saying is that one should not test for one thing in order to get properties of another thing.
your argument is, that the compiler has changed and now refuses (or: refused then) to compile. if this was for good reason, then the code should be fixed (in our case: to use the correct types). if it was for no good reasons, one could try to circumvent the compiler (by taking hand-tailored measures)
anyhow, the problem is not the compiler. it is the header files. thus the problem should not fixed for the compiler but for the headers.
i guess any compiler since OSX-10.2 would probably bail out at the very same spot (and for good reasons).
could you try whether it works.
Looks like Gem built on 10.4 and 10.5, but I have a problem now on 10.4, so its my turn.
.hc
----------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig