PDA

View Full Version : BASIC app, but white lines show up blue?



vertex3f
01-23-2010, 12:17 PM
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( &amp;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;
}


Any help here is super super appreciated!

AGL_Music
01-23-2010, 01:26 PM
When you undo the changes you made to the code, to the lines become white again? If so, what was the original code?

vertex3f
01-23-2010, 01:49 PM
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. =/

marshats
01-23-2010, 04:10 PM
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?

vertex3f
01-23-2010, 04:46 PM
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..

AGL_Music
01-23-2010, 05:37 PM
Well, you can always try glcolor4f just to see if anything happens.

vertex3f
01-23-2010, 05:58 PM
Tried that... no difference... =/ Are you seeing a white line too AGL?

marshats
01-23-2010, 07:10 PM
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


> ldd a.out
linux-gate.so.1 => (0x00b24000)
libglut.so.3 => /usr/lib/libglut.so.3 (0x00599000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00629000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00110000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x004d1000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00136000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00e58000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00bd0000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x0027b000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x0028b000)
/lib/ld-linux.so.2 (0x00cec000)
libGLcore.so.1 => /usr/lib/libGLcore.so.1 (0x00f1c000)
libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0x003f6000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00b55000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00603000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00a20000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00b01000)

What do you get when you run ldd on your compiled executable? It may help me if you post the result.

Now you can manually go through and check the date on each library for instance picking on /usr/lib/libglut.so.3 yields


ls -alF /usr/lib/libglut.so.3
lrwxrwxrwx 1 root root 16 2009-05-19 20:38 /usr/lib/libglut.so.3 -> libglut.so.3.8.0

ls -alF /usr/lib/libglut.so.3.8.0
-rw-r--r-- 1 root root 204656 2008-11-19 04:33 /usr/lib/libglut.so.3.8.0


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.

MaxH
01-23-2010, 11:01 PM
Tried that... no difference... =/ Are you seeing a white line too AGL? 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?

vertex3f
01-24-2010, 12:32 AM
marshats: I'm on Fedora 12 x86_64. I have libglut.so.3.9.0, and the modification date is:



-rwxr-xr-x. 1 root root 290920 2009-11-28 05:44 /usr/lib64/libglut.so.3.9.0*


Running on ldd turned up interesting results...


linux-vdso.so.1 => (0x00007fff0d5d4000)
libglut.so.3 => /usr/lib64/libglut.so.3 (0x00007ff99f90e000)
libGLU.so.1 => /usr/lib64/libGLU.so.1 (0x00007ff99f6af000)
libc.so.6 => /lib64/libc.so.6 (0x0000003e30000000)
libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007ff99f431000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003e37c00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003e30c00000)
libXext.so.6 => /usr/lib64/libXext.so.6 (0x0000003e32c00000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003e31800000)
libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x0000003e42e00000)
libXi.so.6 => /usr/lib64/libXi.so.6 (0x0000003e36000000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003e37800000)
/lib64/ld-linux-x86-64.so.2 (0x0000003e2fc00000)
libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x0000003e38800000)
libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x0000003e33c00000)
libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007ff99f223000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003e30800000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003e30400000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x0000003e32000000)
librt.so.1 => /lib64/librt.so.1 (0x0000003e31000000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003e32400000)


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..



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?

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..

marshats
01-24-2010, 12:45 PM
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 (http://blogs.igalia.com/aperez/2009/01/the-story-of-linux-gatevdsoso/). 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?

vertex3f
01-24-2010, 05:10 PM
The problem just started yesterday. Literally just started...

libGL info...



lrwxrwxrwx. 1 root root 12 2010-01-23 06:20 /usr/lib64/libGL.so.1 -> libGL.so.1.2

-rwxr-xr-x. 1 root root 513616 2010-01-10 22:55 /usr/lib64/libGL.so.1.2


glxgears -info says:


GL_RENDERER = Software Rasterizer
GL_VERSION = 2.1 Mesa 7.7.1-DEVEL
GL_VENDOR = Mesa Project


But my gl.h header says:


* Mesa 3-D graphics library
* Version: 7.6


Could the version difference (7.7 vs 7.6) be an issue?

Also my Driver in my xorg.conf is "radeon".. are there GL libraries / headers specifically for ATI in Fedora / Linux?



EDIT: By the way, everything else works completely fine it seems. Background color, line is in the right place, etc..

marshats
01-25-2010, 12:08 AM
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 (http://www.mesa3d.org/) 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 ;)

vertex3f
01-25-2010, 09:23 PM
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.

1. Downloaded MesaLib-7.6.1.tar.bz
2. Untared, ran ./configure
3. Ran linux-dri-x86-64
4. 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. :p

Any suggestions? I'm still getting a blue line...

marshats
01-25-2010, 10:53 PM
Try temporarily setting your LD_LIBRARY_PATH varible


export LD_LIBRARY_PATH=/usr/local/lib64/GL:${LD_LIBRARY_PATH}

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.

marshats
01-26-2010, 08:54 PM
Note an interesting bug report on Jan 07, 2010 concerning colors and Mesa 7.7 here (http://old.nabble.com/Incorrect-Coloring-of-3D-with-Mesa-td27067534.html) 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.

vertex3f
01-27-2010, 08:54 PM
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. :p It compiles and links and everything, but ldd shows the libraries as missing.

This... is going to drive me insane.

marshats
01-27-2010, 09:43 PM
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.

vertex3f
01-29-2010, 07:11 PM
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.

I'm not sure what compiz is, I'll look into it...

vertex3f
01-31-2010, 07:44 PM
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. :p I still can't seem to get it to link with the other library either.

marshats
02-02-2010, 09:46 AM
What was your make command when you compiled MESA manually?


make linux-x86
or linux-dri or linux-dri-x86 or linux-dri-x86-64 ... etc

If you are on a 64bit OS and compile library for 32bit then I suppose that might cause your linker to "pass over" your MESA library compiled in favor of the already installed 64 bit version in LD_LIBRARY_PATH.

I would try "make linux-x86-64" in your case first to just get the software only version working as a first test then move on to ATI dri if that test works.

vertex3f
02-03-2010, 07:18 PM
Okay the make linux-x86-64 worked, I had tried it with (I think) linux-dri-x86-64 before, or something like that? I can't remember. I get this weird error though when the window opens:



IRQ's not enabled, falling back to busy waits: 2 0


But other than that, directly forcing the link seems to work.... hmm.. so I guess I need to file something with MESA, or maybe Fedora? Or.. I'm not even sure who. lol There was a MESA update released that said it fixed the color problem.. it didn't...

marshats
02-03-2010, 09:58 PM
But other than that, directly forcing the link seems to work.... hmm.. so I guess I need to file something with MESA, or maybe Fedora? Or.. I'm not even sure who. lol There was a MESA update released that said it fixed the color problem.. it didn't...

Sure looks like a MESA issue with the DRI based on your result. Maybe post a bug report with MESA -- tell them your hardware/GPU/OS/64bit and your particular make command option you used. And then ask the fedora forums how to roll back your Mesa driver since it was working for you before the update and let them know why you want to do that ie a problem with the new MESA version relative to your GPU.

ps Do you have a new enough GPU from ATI that may be supported by the binary ie ATI drivers (http://support.amd.com/us/gpudownload/Pages/index.aspx). That may be a way to go until they get the open source support going well. I am all for open source -- it just takes some time and commitment form the manufacturers.

vertex3f
02-05-2010, 04:42 PM
Yeah I tried the ATI drivers before and they totally killed my install.. I'm told they're not compatible with the newest version of X or something. Maybe they've been updated but I'm really hesitant to try though, given when I installed them before, I couldn't even boot to restore. Looking back a linuxlive disc might have worked to get at the xorg.conf that way, but even then I'm not sure as nothing else worked.