[solved] OpenGL Examples in Qt on Solaris not running.

  • I m working on OpenSolaris. I have installed qt and building applications which runs fine. But even the basic examples of OpenGL are not running(But getting compiled fine) What might have gone wrong??

    The error message says (Segmentation Fault(Core Dumped))

    Edit : marked as solved by Eddy

  • What are requirements/libraries that I should have in my system (Solaris) to run OpenGL applications?

    Not jus the Qt/openGL applications but the FreeGult and other applications.

    Please help Me ..

    Awaiting Your reply!!

  • Moderators

    You're really asking two separate questions, I think. If your code compiles and links without errors, then chances are the libraries and things you need are there.

    Can you post a very small compilable sample of some OpenGL code that is crashing? That might help determine whether it's a library issue or an implementation issue.

  • I think its more of implementation issue. the code that i tried is as follows...

    @#include <QtOpenGL/qgl.h>
    #include <QtCore/qvector.h>
    #include <QtGui/qmatrix4x4.h>
    #include <QtGui/qvector3d.h>
    #include <QtGui/qvector2d.h>
    #include <QApplication>

    #include "mainwindow.h"

    int main(int argc, char *argv[])
    QApplication a(argc, argv);
    OGLPort w;
    return a.exec();

    @#ifndef MAINWINDOW_H
    #define MAINWINDOW_H

    #include <QPushButton>
    #include <QGridLayout>
    #include <QtOpenGL>
    #include <QDialog>

    class OGLPort : public QGLWidget

    OGLPort(QWidget *parent = 0);

    void paintGL();
    void resizeGL(int w,int h);
    void timerEvent(QTimerEvent *);

    QPushButton *button;
    QGLFramebufferObject *render_fbo;
    QGLFramebufferObject *texture_fbo;

    #endif // MAINWINDOW_H@

    @#include "mainwindow.h"
    #include <GL/glut.h>

    OGLPort::OGLPort(QWidget *parent) :
    setWindowTitle("My OpenGL Trial");

    void OGLPort::paintGL()
    glColor3f (1.0, 1.0, 1.0);
    glOrtho(0.0, 1.0, 0.0, 1.0, -1.0, 1.0);

        glVertex3f (0.25, 0.25, 0.0);
        glVertex3f (0.75, 0.25, 0.0);
        glVertex3f (0.75, 0.75, 0.0);
        glVertex3f (0.25, 0.75, 0.0);


    void OGLPort::resizeGL(int w, int h)
    int side = qMin(w, h);
    glViewport(((w - side)/2), ((h -side)/2), side, side);

    void OGLPort::timerEvent(QTimerEvent *)

  • But why is it that the Qt-OpenGL examples not running.., though its compiling fine??

  • Hello Again Vijaeendra,

    As you know I might not be the best person to answer that to you. I am only answering this, because I was waiting for the other guys with Unix knowledge to answer.

    First and of Ultimate Importance:
    Please provide us the Video Card you are using and also the driver version.
    Maybe the thing is that your card really does not support these features.
    Man, in openGL one thing is always true, keep everything current, really :-) , this is important.

    Last: Libs and libs
    Another thing, some OS provided OpenGL lib versions are really old (like 1.1). OpenGL itself, as I told you, is really moving forward fast. Also, several board manufacturers use extensions that are registered with the name _EXT (functions, defines, etc.). Sometimes these features, such as Framebuffer Object, Geometry Shader, Mesh refinement, OpenGL 3.0, OpenGL 4.0 (yeah, crazy huh?), etc. are only available through these special packages. That is, programming with new features (openGL 3 and 4) sometimes might require these these special libs.

    pBuffer itself is really old (Approved by ARB on December 7, 2004.), however, you are using a system that is not directed to Graphics. Thus, I believe your openGL version is indeed old (old defines, old functions, etc.). Try to use glew, "The OpenGL Extension Wrangler Library":http://glew.sourceforge.net/ . It overwrite old stuff with new stuff. There is Also something called GLEE, but I never used it.

    You can download the source code and compile it to your system. Take a good look at the documentation, but some advises:
    -Include glew header before any opengl include
    -in the initializeGL the first thing you must call is glewInit()

    @ //Starting GLEW
    GLenum err = glewInit();
    if (GLEW_OK != err)
    If your problem is not old hardware and drivers, this might solve your problem.

    Otherwise... time to go shopping :-) . I will explain you why: old video cards were only prepared to use a fixed pipeline, newer cards now use a programmable pipe line with shaders and stuff, if your card is old, you will never be able to do the actual heavy metal stuff available with OpenGL.

    Use newer cards such as NVidia GeForce 6 and up, for ATI I don't remember the first one to use programmable pipeline, but you can use any of the HD series.


  • I totally appreciate your help VitorAMJ !!

    Well, I dont have a separate video card as such. Its Intel(R) 4 Series Interface Chip and driver version ( on windows.... But solaris i m running on VirtualBox. I m not sure how to get the Graphic info on solaris.

    But what is baffling me is that if its a Graphic card issue, why is it that the applications are running fine on Ubuntu(On VirualBox) and Windows( On the same system)

    I also learnt that there is no OpenGL support on Solaris/x86 systems.., but its there only for Solaris/Sparc systems... But yes, there is 3rd party support like Mesa3D , Xi etc. have to try with that...


  • Because there is no problem with the program, it is even telling you that it cannot do anything with the tools it has.

    There are ways for the OpenGL backend to know when a call leads to unavailable driver/hardware features. For instance, there is the very basic glGetError, and even the glew library I just mentioned comes with two executable files that show you the tricks your board support, its called glewinfo or something,...they generate a txt that you can read to understand your hardware/driver limitations.

    In your program you declare QGLFramebufferObject, which is a somewhat new feature (fast backstage screen processsing), it somewhat replaces pBuffer with restrictions of size and context change modifications.

    However, you are saying that these programs run on Ubuntu and Windows using VirtualBox (from Solaris, right?). I am no VirtualBox user, but this adds complications, since we don't know which driver each OS is using (software emulation/direct driver access). But since Solaris is the base OS, it is certainly using its own, possibly faulty/old, driver.

    Anyway, from your info, your board seems to support the things you do (with good drivers), and it leads me to think that you have a driver problem on Solaris only. I have seen from Intel, that OpenSolaris/Solaris is not in the list of supported OSs. You have to obtain the driver version used by your Solaris and almost for sure download and install a better one. Unfortunately, I am less than a newbie to help you on that :-(

    bq. Vijaeendra wrote:
    I also learnt that there is no OpenGL support on Solaris/x86 systems.., but its there only for Solaris/Sparc systems… But yes, there is 3rd party support like Mesa3D , Xi etc. have to try with that…

    Not optimistic about mesa3D, but remember to test that with and without glew. And also glew alone with Qt.


  • Do the things we have been discussing. If those do not work, I've been thinking:
    Download or compile glew for your Solaris
    Download or compile glew for your Ubuntu
    Download or compile glew for your Windows

    Using the glew info, compare if there are differences between the supported driver features such as the framebuffer_object for each of your systems. Run them natively (not on Virtualbox). After this test, run all of them from Virtualbox (including Solaris from another OS). This way you will get a clearer picture of your systems and limitations with and without the Virtualbox

    Finally, but again I am not that optimistic:
    If you are lucky, your Solaris, when run from other OS inside the Virtualbox, might use the driver of Windows/Ubuntu to access the Graphics Card instead of its own. If that works, it might be a workaround for you.


  • Mesa 3D worked..., and That was all it needed... Sorry had fixed it long back :P

    Thanks for all the help VitorAMJ

  • Moderators


    Please mark your topic as solved the next time! so we can avoid putting efforts that are no longer needed.

    Sharing your solution with the community is well appreciated also. ;)

  • I have alreday shared the solution Eddy.., :-)

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.