Glut not working on Redhat 9 (shrike)

The following code seems to work fine on Solaris 8 SPARC (here at work), but won’t draw anything on Redhat linux 9 (at home).

Has anyone had any issues with glut on RH9?

// tester.cpp

#include <GL/glut.h>

//================================================
void my_init();
void my_display_func();
void my_reshape_func( int w, int h );

//================================================
int main( int argc, char * argv[] )
{
    glutInit( &argc, argv );
    glutInitDisplayMode( GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH );
    glutInitWindowSize( 600, 600 );
    glutInitWindowPosition( 50, 50 );
    glutCreateWindow( "tester" );

    my_init();

    glutDisplayFunc( my_display_func );
    glutReshapeFunc( my_reshape_func );

    glutMainLoop();
    return 0;
}

//================================================
void my_init()
{
    glClearColor( 0.0, 0.0, 0.0, 0.0 );
    glEnable( GL_DEPTH_TEST );
}

//================================================
void my_display_func()
{
    glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );

    glColor3f( 0.1, 0.7, 0.3 );
    glBegin( GL_LINE_STRIP );
        glVertex3d(  0.2,  0.2, 0.0 );
        glVertex3d( -0.2,  0.2, 0.0 );
        glVertex3d( -0.2, -0.2, 0.0 );
        glVertex3d(  0.2, -0.2, 0.0 );
    glEnd();

    glutSwapBuffers();
}

//================================================
void my_reshape_func( int w, int h )
{
    if ( w > h )
    {
        glViewport( w/2 - h/2, // x_bottom_left_corner
                    0,         // y_bottom_left_corner
                    h,         // width (x, to the left)
                    h );       // height (y, up)
    }
    else
    {
        glViewport( 0, h/2 - w/2, w, w );
    }

    glMatrixMode( GL_PROJECTION );
    glLoadIdentity();
    gluPerspective( 35.0,  // fovy
                    1.0,   // aspect
                    2.0,   // near
                    6.0 ); // far

    glMatrixMode( GL_MODELVIEW );
    glLoadIdentity();
    gluLookAt( 0.0, 0.0, 4.0,   // eye position
               0.0, 0.0, 0.0,   // looking at
               0.0, 1.0, 0.0 ); // which way is up

    glutPostRedisplay();
}

BTW… did you download the RH glut RPM’s…
both the runtime and dev ones?

Didn’t need to – they were on disk 2 I believe (I bought the rh9 box). I installed them manually from there.

Also note, I first posted this message in the beginner area (before realizing that it was a linux-specific issue) and I mentioned there that glxinfo tells me direct rendering is enabled. Also, glxgears runs very fast.

I’ve got a Matrox G400 Millenium.

Per my last post, later when I am home will download your example on my linux machine.
And check it out.

Originally posted by jmg:
[b]Didn’t need to – they were on disk 2 I believe (I bought the rh9 box). I installed them manually from there.

Also note, I first posted this message in the beginner area (before realizing that it was a linux-specific issue) and I mentioned there that glxinfo tells me direct rendering is enabled. Also, glxgears runs very fast.

I’ve got a Matrox G400 Millenium.[/b]

It draws three green lines in my case wich looks like what it should be doing.I’m running Debian.Btw does it just draw a black screen in your case or does it crash with some error message?

> It draws three green lines in my case wich
> looks like what it should be doing.

Yup, that’s what it should do.

On RH9, it opens the window, doesn’t crash, and doesn’t draw anything (well, except for a black background). Also, resizing the window seems just a bit slow to me, but the background remains black.

Thanks for trying it zen.

I’m asking around elsewhere, and I’ll post when I find anything out.

Am I the only one here using glut on RH9? :slight_smile:

Works for me.

$ uname -a
Linux localhost 2.4.19-gentoo-r10 #6 SMP Thu Feb 6 16:48:24 PST 2003 i686 AMD Athlon™ Processor AuthenticAMD GNU/Linux
$ gcc -v
gcc version 3.2.2 20030322 (Gentoo Linux 1.4 3.2.2-r2)
$ glxinfo

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce3/AGP/3DNOW!
OpenGL version string: 1.4.0 NVIDIA 43.49

$ emerge -s glut
Searching…
[ Results for search key : glut ]
[ Applications found : 1 ]

I got three green lines under Red hat 8.0.

Thanks. I just left on vacation, so all I’ve got is my debian Powerbook :slight_smile: and the code, of course, works there. When I get home, I’ll try rebuilding glut from the glut src rpm’s and see if that works.

EPILOGUE:

Well, I never got HW-accelerated OpenGL working. I didn’t hear back from anyone on comp.graphics.api.opengl or redhat’s xfree list, which surprised me…

Anyhow, in the end, I just downloaded Mesa, ran the standard ./configure, make, su root, make install; and everything went into /usr/local.

I tried rebuilding my little test app with a -L/usr/local/lib before the -lglut -lGLU -GL but it didn’t work! (?) The app still linked with the libs in /usr/lib --> /usr/X11R6/lib. I thought when you tell g++ -L/foo that it looks in /foo first before checking other locations for the libs, but that doesn’t seem to be what’s happening here. If anyone can tell me what’s going on, I’d appreciate it.

Well, as root, I removed the OpenGL lib symlinks in /usr/lib that pointed to /usr/X11R6/lib and made new ones pointing to the libs in /usr/local/lib – and now I’ve got software-rendered OpenGL in Redhat 9.

As near as I can figure, the default install for glut on RH9 is broken. [shrug]

—j

Originally posted by jmg:
[b]EPILOGUE:

Well, I never got HW-accelerated OpenGL working. I didn’t hear back from anyone on comp.graphics.api.opengl or redhat’s xfree list, which surprised me…

Anyhow, in the end, I just downloaded Mesa, ran the standard ./configure, make, su root, make install; and everything went into /usr/local.

I tried rebuilding my little test app with a -L/usr/local/lib before the -lglut -lGLU -GL but it didn’t work! (?) The app still linked with the libs in /usr/lib --> /usr/X11R6/lib. I thought when you tell g++ -L/foo that it looks in /foo first before checking other locations for the libs, but that doesn’t seem to be what’s happening here. If anyone can tell me what’s going on, I’d appreciate it.

Well, as root, I removed the OpenGL lib symlinks in /usr/lib that pointed to /usr/X11R6/lib and made new ones pointing to the libs in /usr/local/lib – and now I’ve got software-rendered OpenGL in Redhat 9.

As near as I can figure, the default install for glut on RH9 is broken. [shrug]

—j[/b]

This sounds like a reasonable workaround. What might get your HW acceleration back is to remove the link to the mesa built libGL, and put back the origional libGL links. glut, and glu are software librarys, libGL is the only HW accelerated lib.

Jamie

| What might get your HW acceleration back is
| to remove the link to the mesa built libGL,
| and put back the origional libGL links.

Yow! Good suggestion.

[time passes]

Nope, didn’t work. Thanks though.

Btw, any idea why the -L/usr/local/lib didn’t work for me? The man page says it adds the directory to the list to search, but doesn’t say whether it adds it to the front or the back of that list. I guess it’s added to the end. (?)

What’s even freakier is that if I just skip the -lfoo and do something like

g++ main.o -Wall -ansi -pedantic-errors -o glut_tester /usr/local/lib/libglut.so /usr/local/lib/libGLU.so /usr/local/lib/libGL.so -L/usr/X11R6/lib -lXmu -lXi

I still get

[john@quartz ~/dev/cpp/glut/tester]$ ldd glut_tester
libglut.so.3 => /usr/lib/libglut.so.3 (0x40028000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0x4005d000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x400da000)

Any insight anyone could offer here would be great. :slight_smile:

[This message has been edited by jmg (edited 04-18-2003).]

I’m most-likely not the best one to be giving advice here. I usually get things to work, but have little interest or patients in getting os configurations to be correct – yet I don’t let it stop me from giving advice

If you look in /etc/ld.so.conf you will see something like this:

/usr/kerberos/lib
/usr/X11R6/lib
/usr/lib/qt-3.0.5/lib
/usr/lib/sane
/usr/lib/qt-3.1/lib

you need to add this to the beginning:
/usr/local/lib

then run /sbin/ldconfig

this will set up your dynamic linker to look in the right places.

If you place the “/usr/local/lib” line first it should get searched first

Jamie

PS:

I think you should revisit the libGL issue again. It sounds to me like you may have some link pointing to the wrong place still. All it takes is for one stray software version of libGL to be in your path and things can get messed up…

use glxinfo and ldd on glxgears to see where the hw accel libs are…

Jamie

Thanks Jamie,

I don’t have /usr/local/lib listed in my ld.so.conf.

The way I understand it, an application only knows what libs it needs to link to – it doesn’t know where they might reside on your harddisk. This makes sense to me, since, if I run “strings” on my executable, it only coughs up library names – no paths for them. :slight_smile:

So, when you run an executable, ld.so says, “ok, relax, I’ll find you your libs”, and checks its cache (built with help from ld.so.conf, while you run /sbin/ldconfig).

Check.

So, when I linked up my little glut app, even though I told it explicitly where to get the libs to link to, it actually only had the library name itself baked into the binary. Then when I ran ldd, it was the same as asking, “when I run this app, which libs will we be linking to?”. Ok, got that. Thanks. :slight_smile:

I notice that /usr/lib is not in ld.so.conf. I think that this directory is special and always gets checked first. Even though I just updated my ld.so.conf and put /usr/local/lib as the first entry, ldd was still telling me that my little app was linking to /usr/lib/libFoo.so.

Regarding the libGL issue, I can change the links back and forth, and alternate between glxinfo telling me I’m using direct rendering and Mesa rendering, so I think I’m not missing a symlink anywhere.

I’m happy with software rendering for the time being (my current project is more cpu-intensive anyway). I did let the redhat xfree list know about this, and still haven’t heard back, so my guess is that this is a real issue and that maybe someone at RH is working on a patch. :slight_smile:

[This message has been edited by jmg (edited 04-18-2003).]

You shouldn’t have to care as to where ld looks first for libaries as it is not a wise idea to have multiple libs with the same name in different places in the first place. My advice would be to delete all libGL.so, libGLU.so, libglut.so etc. and simlinks to them and reinstall either the HW or SW library. You might want to save a copy of libglut.so from the mesa sources if it works better than the official redhat one. Then run ldconfig and make sure all libraries are found and everything should work correctly (it probably won’t of course, but it still should).

There’s one more trick that is much cleaner than my previous suggestion:

in your shell do this:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

this will setup your library path for that shell’s session without screwing up your system

Jamie

Originally posted by jmg:
[b]The following code seems to work fine on Solaris 8 SPARC (here at work), but won’t draw anything on Redhat linux 9 (at home).

Has anyone had any issues with glut on RH9?
[/b]

I just tested your prog on my RH9 install and got only some linking problems with glut. So I downloaded the source rpm, rebuilded it and everything works fine.
Btw I upgraded from RH8 via apt-get dist-upgrade and then installed the NVIDIA driver.
So to me it does not look like it is a RH9 problem (except the glut probs but that’s because MESAs glx has some function defined that NVIDIAs glx does not have).

Thanks satan,

Though, I’ve got a Matrox G400 and so am using the DRI drivers built into xfree86. Note, I didn’t get any linking problems like you did – rather, my app ran, but just didn’t display anything.

Also, I didn’t upgrade, but instead bought the COTS RH9 box and did a clean install.

I went to http://www.redhat.com and clicked on the download link. Did a search there for “glut”, and saw listed there glut-3.7-8 and glut-devel-3.7-8, both dated August 2002 (RH8 vintage I believe). The ones currently installed on my system are 3.7-12, and that’s what I see listed if I drill down into the rh9 dirs on their ftp site.

Say, after I install the src rpm, how do I build and then install what I just built?

Do I need to remove the non-src glut rpms before moving ahead with the src rpms?

[This message has been edited by jmg (edited 04-19-2003).]

Since you don’t have any linking problems with glut I think that it will not help much to recmpile glut. To me it looks like a problem with your hardware/driver.
At least I can tell you how to build rpms:

rpmbuild --rebuild *src.rpm

to install it you have to remove your already installed rpm or use --force to install your newly builded package due to file conflicts as both packages provide the same files, of course

the newly build package can be found in /usr/src/redhat/RPMS/i386/

sorry that I cannot help anymore since I do not have any experience with matrox cards or dri drivers

p.s.:did you check your kernel settings?

p.p.s. erhaps taking a look here helps http://groups.google.com/groups?hl=en&lr=&ie=ISO-8859-1&q=xfree86+matrox+g400+dri&btnG=Google+Search

[This message has been edited by satan (edited 04-19-2003).]

> Since you don’t have any linking problems
> with glut I think that it will not help much
> to recmpile glut.

Understood.

> rpmbuild --rebuild *src.rpm

Ahhhh! A 2nd rpm command. :slight_smile: Thanks!

> to install it you have to remove your
> already installed rpm …

Doh. :slight_smile: Thanks.

> sorry that I cannot help anymore …

Ha! Satan, you’ve helped me a great deal. Thank you. :slight_smile:

> p.s. did you check your kernel settings?

No. That’s a little beyond my level of linux sophistication. Currently, I’m working on my first raytracer, and don’t even really require HW accelerated OpenGL at the moment – I’m just using glut to manage the window and let me use glDrawPixels().

What’s so weird about this is that (looking back at my original posts) HW accel OGL does indeed work. There’s no problem with that. It’s just that building with the default redhat glut/glut-devel libs gives me something that doesn’t work at all (though it builds and runs – just doesn’t draw anything). I’m sorry if I confused the issue in my first sentence of my “EPILOGUE” post.

Thanks again all,
—j