octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: A first short test


From: Ben Abbott
Subject: Fwd: A first short test
Date: Thu, 05 Feb 2009 07:35:45 -0500

David/others

Thomas and I have encountered a problem that we hope you can help out with.

We've been working on this off-list, but are now looking for some help.

Thomas is working on adapting Octave's build process so that it builds properly on Mac OSX 10.4 and 10.5 with no hassles (no need for the individual to pass specific options to configure). The problem he encountered that has halted his progress is one I have some faint memory of seeing a few (several?) months ago ... my recollection is that you were able to resolved the problem (I may be wrong about this, so I've cc'd the list in the event it was jwe or someone else).

The relevant part of the exchange between Thomas and I is below. If you or someone else has the time to help out, it would be appreciated!

Ben

Begin forwarded message:

From: Thomas Treichl <address@hidden>
Date: February 5, 2009 2:46:58 AM EST
To: Ben Abbott <address@hidden>
Subject: Re: A first short test

On Feb 4, 2009, at 4:02 PM, Thomas Treichl wrote:
Ben Abbott schrieb:
On Feb 3, 2009, at 3:58 AM, Thomas Treichl wrote:
Hi Ben, just to make sure once again:

The second one gives an error.

$ g++ -framework OpenGL testc.cc
testc.cc: In function ‘int main()’:
testc.cc:12: error: invalid conversion from ‘GLvoid (*)(...)’ to
‘GLvoid (*)()’
testc.cc:12: error:   initializing argument 3 of ‘void
gluTessCallback(GLUtesselator*, GLenum, GLvoid (*)())’

... means that the first one does not give an error?
Correct, the first one gave no error.

Ok, from what I've seen until now:

- the problem appears on the current 10.5.x system
- framework OpenGL API between 10.4 and 10.5 has not been changed
- compiling on 10.5 against SDK 10.4 doesn't change anything
- the example program can be compiled if not "(...)" is used

Ergo: it's the compiler. I don't know if it is a bug or if the
compiler has been changed (ie. it is a feature?). I have not been
able to build a small example program that illustrates the problem
in short. So I think there is nothing more to do than to create the
configure.in test now and to set up framework OpenGL for both of us
in a different way...

I'll continue replying to the our thread on the list tomorrow (or
the day after, or the day after, or the day after ;). Meanwhile best
regards,

Thomas

PS. I found this reference that is exactly our problem

http://www.openframeworks.cc/forum/viewtopic.php?t=269

Thomas,

Looking at that link stirs a memory of another problem I had.
Unfortunately, I do no recall the context.  However, I have some
recollection that David fixed the problem. I'd estimate this occurred
in Oct-Dec. The part I recall is an issue regarding
"void(<<somethinghere>>)(...)" vs "void(<<somethinghere>>)()" ... or
vice versa.

I don't know if testing David's memory would help, but if you think it
would help I can ask him.

Oh yes, that would be great if you could do that. If it would be possible to write a 3..5 lines long program that shows the problem then we can easily create a preprocessor macro for either a) "..." or b) "(...)".

The other solution would be that I create HAVE_FRAMEWORK_OPENGL_NEW and HAVE_FRAMEWORK_OPENGL_OLD which actually is not the right way to do and I think it wouldn't be accepted...

Thanks,

 Thomas
--
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/? ac=OM.AD.PD003K11308T4569a




reply via email to

[Prev in Thread] Current Thread [Next in Thread]