View Full Version : Segmentation fault at glGetString()
Im trying to port my library from Win32 to Linux. Im currently using Ubuntu.
1)However when i run a simple program with the library, i get a segmentation fault. I looked up my log file and my source code which points all fingers to glGetString(GL_VENDOR); So far i have not played any games on Linux so i don't even know if there is any hardware acceleration. But im pretty sure i read somewhere that Ubuntu automatically installs ATI drivers if it detects the hardware.
On Google, the problem appears to be pretty common as well but i cant seem to find a solution.
2)Im also using the MESA-dev package and linking to the libGL.a/libGL.so provided by that package, so will i still get hardware acceleration? Or will i have to link to ATI's GL.so/GL.a(Whereever in the world they may be)? Does that mean that if i were to distribute this prog to other linux users, they will require the src code in order to compile and link to their gfx card vendor's GL.a/GL.so?
The fact that you get an error on getting string could be a product of several errors: whether you use it too early, whether the driver is 'really' buggy (or bad installed), or whether you have several problems with pointers. Try out glxinfo and tell me if it works.
That you have several gl libraries might enforce your problems. Did you ensure only one is linked at a time ? Generally, if several 'same' libs exist and are found, this can provoke bad stuffs.
Finally, any GL libraries have to respect the interface as specified by ARB (and the goals of the implementation of course). So, this means people won't need to take your sources back in order to compile.
Hmm i cant be using it too early because the same code works fine in Windows. Im using GLFW to handle the windowing stuff and it does create a window for less than a sec b4 the segmentation fault.
I did suspect it to be drivers, so i installed the latest ATI's drivers and the GLinfo program which comes with the drivers shows Vendor as ATI and not MESA. The test applications which come with the driver also work fine with the pBuffer demo running at 200+ fps.
About the linking, im not sure what to link my prog with. I thought .so files were like dll's in windows and did not need to be explictly defined at compile time, but it appears that i need to link them to one. Im at a total lost as to what else could be causing it.
04-17-2005, 01:08 PM
I read your post on the GLFW forum (and replied, though it may not be of much help). Anyway, the best thing you can do to track this down is to write a minimal test program that reproduces this bug (hopefully only a few lines of code). If you still suspect GLFW after that, I could have a look at your code and see if I can figure out what's wrong (either with your code or with GLFW).
About the linking, im not sure what to link my prog with. I thought .so files were like dll's in windows and did not need to be explictly defined at compile time, but it appears that i need to link them to one. Im at a total lost as to what else could be causing it.Just link with /usr/lib/libGL.so (or /usr/lib64/libGL.so). You can do this by adding -lGL on your link command-line. If a particular hardware vendor needs a "special" version of libGL.so, it will be put there.
You mean we don't link to the .a file like we link with .lib files instead of linking dlls directly in Windows?
We do not really know where to look at. We have so few things in order to think at so we wonder what could be your problem. Please give more information.
The fact that your program segfaults on glGetString(GL_VENDOR) generally means you call it too earlier. But maybe it segfaults on it due to an earlier error and noone here is god enough to discover that, but only you.
That might not depend on the gl library you linked with, as long at it is a real gl full compatible library, like Mesa.
But that might also mean you have some problems inside your library. You know, a program that compiles doesn't mean that this program will run without any error at all... Did you tried to debug it ? Did you ensure your code is 100% ISO C or C++ compatible ?
For hardware acceleration, I guess this is not yet time as your program simply crashes. So see that later.
Hope that could help.
You mean we don't link to the .a file like we link with .lib files instead of linking dlls directly in Windows? The linker will pick the .a or the .so for you (when both are available). As long as you're doing dynamic linking, which you should almost always be doing, it will pick the .so. In actuality, you shouldn't even have a libGL.a on your system. If you want to know what dynamic libraries your program is going to use, run ldd on it (i.e., "ldd myprogram").
It's alright now, i found out that i was not linking with the correct libraries, and im getting hardware acceleration with my program running slightly faster in Linux than in Windows.
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.