ill appreciate it if any sdl users would look at this thread http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/008307.html
- quickly test out the program (to see if they segfault as well)
ie perhaps eveything aint alright on my machine
Well, I didn’t appear to have any troubles using it myself. I just got an endless listing of “glSecondaryColorPointerEXT test ass”. However, I assume you are using NV, and not ATi like me, but it is atleast working. My specs…
Minimal Debian 3.0r0 install
custom built the following packages (or those that seem important to you)…
Intel Pentium !!! - S 1.4GHz
ATi Radeon 8500LE
FireGL-2.5.1 for XF86-4.2.0
#include “glext.h” should be #include <GL/glext.h>
And for people who don’t know how to use a compiler directly, use this to compile:
gcc file_with_copy_pasted_text.c -I/usr/include -lSDL -lGL -lpthread
Okay, and here are my results:
glSecondaryColorPointerEXT test:Fatal signal: Segmentation Fault (SDL Parachute Deployed)
Red Hat 8.0 (Psyche)
glibc 2.2.93-5 (RH8)
gcc 3.2-7 (RH8)
XFree86 4.2.0-72 (RH8)
SDL 1.2.4-5 (RH8)
Gnome 2.0 (RH8)
GeForce3 Ti 200
>>#include “glext.h” should be #include <GL/glext.h><<
i have tried that (with the saem results). i just use “glext.h” to try out a different header version (which of course shouldnt make a difference but you never know)
ok it works on dan’s ati card but not on richard or mine nvidia cards.
also i notice dan has sdl1.2.5 but me + richard 1.2.4.
im downloading sdl1.2.5 at the moment, i will install + try again (hopefully thats the problem)
ill let you guys know what happens.
i would still like though more results from ppl as this will let me able to find out the exact cause of the problem, so i can put some info up on my site for ppl when they try out KEA + it crashes when the extensions are ‘gotten’
1.2.5-1 didnt help
[This message has been edited by zed (edited 12-25-2002).]
One of our developers has looked at your test, and thinks that there is a problem with the run-time symbol resolution that we are doing in the driver for glXGetProcAddress. It appears that the address we are returning in GetProcAddress is actually the address of your variable, not the address of our function.
Apparently, renaming your variables to something other than the standard GL function names will eliminate the crash. I would speculate that you might not see this problem if you stripped your executable. Just a guess.
It’s not clear to me (a non-Linux user) whether this is a driver bug or a Linux run-time bug. But in either case, a fix (or workaround) in the driver will probably be necessary, and is being investigated.
Hope this helps,
(p.s., I don’t generally follow the Linux board, so if you want to follow up with me, please do so by email.)
[This message has been edited by pbrown (edited 12-26-2002).]
This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.