I’ve been working on learning opengl from the red book… I was working on a small app that was working well when suddenly… all of my lines went from white to blue? I rewrote a skeleton that was basically as small as I could make it… lines are still blue… I don’t see anything I’m doing wrong, I’ve checked it against other examples, but… I obviously must be. Can someone see an obvious problem?
#include <iostream>
#include "GL/glut.h"
using namespace std;
void reshape(int w, int h)
{
glMatrixMode(GL_PROJECTION);
glViewport(0, 0, w, h);
glLoadIdentity();
gluOrtho2D (0.0, w, 0.0, h);
glMatrixMode(GL_MODELVIEW);
}
void draw( ) {
glMatrixMode( GL_MODELVIEW );
glLoadIdentity();
glClear( GL_COLOR_BUFFER_BIT );
// set the pen color = white
glColor3f( 1.0, 1.0, 1.0 );
glBegin( GL_LINE_STRIP );
glVertex2f( 100, 100 );
glVertex2f( 200, 200 );
glEnd();
// but it shows up as blue?
glFinish();
}
int main( int argc, char** argv ) {
glutInit( &argc, argv );
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB);
glutInitWindowSize(300, 300);
glutInitWindowPosition(200,200);
glutCreateWindow("helloworld");
glClearColor( 0.0, 0.0, 0.0, 1.0 );
glutDisplayFunc( draw );
glutReshapeFunc( reshape );
glutMainLoop();
return 0;
}
I don’t even remember where this happened. I’ve been working / fighting with it so long. But this basic app, I can’t find anything wrong with it. I did some linux updates, maybe my glut library got messed with? But I doubt it. I don’t understand. =/
Is the code actually compiling? Try replacing the line
#include "GL/glut.h"
with
#include <GL/glut.h>
The reason I ask is because the code doesn’t even compile on my machine until I make the above change. But if I make that change then yes, I see a white line. And if you are thinking it compiles but it doesn’t then you are possible running an old compiled version of the code that happened to have a blue line?
It compiles. I’m currently using JUST the code above. Totally seperate side app. Still a blue line… if I change it to glColor3f(1.0, 0.0, 0.0) the line disappears completely?
EDIT: It compiles with “” or <> I meant. This started happening about the same time a bunch of linux updates got pulled… might it be related? If so… any idea how I could fix it? I’ve cleaned and rebuilt a million times…
I would be surprised if an update caused this – but what system are you on? I am on Ubuntu 9.10 and just did some updates without any problems like you describe.
If you suspect a library problem do the following
g++ main.c -lglut (or whatever your compile command is)
ldd a.out (or whatever your executable name is)
This gives me a listing of all the libraries linked as
From there let us know if there are any changes in dates after your suspected update date … For me I keep my system up do date (Ubuntu 9.10) and you see the installed GLUT hasn’t changed for over a year.
I just compiled this on a Windows platform and it worked fine. Got a white line. Is it possible that the red and green components in you glColor command are being ignored? If you try using (0,0,0.5) instead of (0,0,1), do you get a darker blue line?
I’ve NEVER seen a glut app on any of my machines linking against “linux-vdso.so.1” or “libXxf86vm.so.1”… and that was from just compiling using “gcc main.cpp -lglut -lGLU”… there’s a LOT of others there I don’t recognize, or at least haven’t seen there before…
That does work, yes. Evidently the red and green are being discarded somehow…
This HAS to be some sort of update related to SOMETHING. I can compile it via command line or Codeblocks and get the same result, and it works on Ubuntu and Windows as it should…
This is all very strange. I have never seen a problem like this in linux and I’ve been using linux for >10years on many different distributions: slackware, gentoo, redhat, ubuntu, …
I’ve NEVER seen a glut app on any of my machines linking against “linux-vdso.so.1” or “libXxf86vm.so.1”… and that was from just compiling using “gcc main.cpp -lglut -lGLU”… there’s a LOT of others there I don’t recognize, or at least haven’t seen there before…
As for linux-vdso there is an interesting story at vdso. The other libraries like libXxf86vm get pulled in by libraries like glut and GL implicitly … Actually I don’t know which does just know that they have their own dependencies themselves. In years past I used to have to add the -lXi -lXext -lothers manually to the compile line but that faded away over time. In other words if you had to compile GLUT yourself then you would see it does have dependencies, especially to use the X11 code to get glx* functions etc. That is normal. Seeing the date on your glut library of 1.5 months is rather new – Did your problem start around that time or more recently?
Since the problem is observed in the glColor command – the problem is more likely in your GL library itself. What is your GL library? ATI/NVIDIA/Intel/MESA? What is the date on your /usr/lib64/libGL.so.1 file?
I suspect your Mesa driver as being the problem – in my opinion the header mismatch probably wouldn’t cause the issue. Mesa is your “libGL.*” file and some others so I would start there.
I went over to Mesa and saw that “Mesa 7.7 is a new development release. People who are concerned with stability and reliability should stick with a previous release or wait for Mesa 7.7.1.”. Mesa 7.6 was released December 21, 2009 and is considered stable. Do you have the option to roll back your Mesa driver to 7.6? If not one route would be to download the Mesa 7.6 source, read the install instructions at the above webpage, and link your simple glut program to the 7.6 library, hopefully the blue line will be white …
In Linux I have stuck with Nvidia cards due to their support over the years = I am not knowledgeable about ATI in linux. But maybe you could post what model number of your ATI card you have in the openGL linux forum ie start a new thread to see if/how you can get ATI hardware drivers. I have heard good news about newer ATI cards having excellent drivers in Linux so you may be in luck depending on your particular card. And get a tremendous openGL speed boost in the process
Having a bit of difficulty here. Maybe you can point me in the right direction. I’m not always the best with this kind of thing.
Downloaded MesaLib-7.6.1.tar.bz
Untared, ran ./configure
Ran linux-dri-x86-64
Ran sudo make install
diff says the libraries it created ARE different, but I can’t get it to link against them… it installed them to /usr/local/lib64/GL and not /usr/lib64/GL and I’ve tried compiling with -L/usr/local/lib64 and it’s skipping over them.
EDIT: I forget but you may have to run “sudo ldconfig” before the compile step.
then compile and run your glut program.
To summarize, what worked for me:
after downloading and compiling mesa ...
export LD_LIBRARY_PATH=/home/marshats/Desktop/tmp_Mesa7.7/Mesa-7.7/lib:${LD_LIBRARY_PATH}
sudo ldconfig
g++ test.c -lGL
ldd ./a.out | grep marshats
./a.out
Note an alternative but less recommended alternative – you could also temporarily set your global file /etc/ld.so.conf and put at the top beginning a line (but please make a backup of whatever file you edit first!)
/usr/local/lib64/GL
save and exit. Then run as root
sudo ldconfig
now try and compile and run your example and it should link with your needed MESA lib. Note you shouldn’t use this method often since you really don’t want to be setting global linker paths. It is best to let your distribution control this file. However, if this temporary test works (blue line becomes white) then I suggest undoing the above edit and recompiling your MESA lib to be installed in /usr/lib64/GL permanently and report a bug to Fedora+Mesa3D to help them resolve this for others.
Note an interesting bug report on Jan 07, 2010 concerning colors and Mesa 7.7 here seems to confirm that the problem is with the latest Mesa library on ATI hardware … I would be curious if the previous post rollback to 7.6 works for you.
Sorry I’m so delayed getting back here. It’s good to know I’m not the only one having issues.
Alright so really strange issues with trying to link against those bloody libraries… tried both methods you suggested and neither have worked for me, and I don’t know why because they’re both pretty straight forward.
Exporting the LD_LIBRARY_PATH didn’t do any good even after ldconfig, it still links against lib64/libGL… I tried adding to the ld.so.conf file, AGAIN it links to the lib64/libGL… I tried renaming the files in lib64 to libLG temporarily and trying to FORCE it to use the ones in /usr/local/lib64… and it didn’t find them. It compiles and links and everything, but ldd shows the libraries as missing.
Just one more thing to try – Since this is a temporary test – you have to run the executable from the same window were you set LD_LIBRARY_PATH. For example if I complete the steps provided in my previous post setting LD_LIBRARY_PATH then “ldd my_executable” shows the Mesa 7.6 library being the one used. If I then open a new terminal and CD to same directory – “ldd my_executable” will show my non-mesa (in my case NVIDIA installed library) library path because the path was not set globally (ie set in another terminal).
However the editing /etc/ld.so.conf will be permanent on reboot, but ldconfig will only update it in the terminal in which it was run.
On a separate test, Do you happen to have compiz or the like enabled? Try disabling it and running your code linked to the original Mesa 7.7 lib.
Yeah I did that all from the same window… it still shows linking against the /lib64 library. I can’t figure out why. Editing the ld.so.conf didn’t work either.
Okay I looked at compiz, and no I don’t have that… and a new MESA lib got downloaded just the other day that said it fixed the color problems anddddddddd… it didn’t. I still can’t seem to get it to link with the other library either.
