From: FragDance G. <fra...@ho...> - 2000-05-20 13:33:21
|
That is because (as I understand it) the windowed mode on a Voodoo3 is a hack. Voodoo3 is designed to run in fullscreen, and Mesa allows Voodoo3 to run in a window by first rendering to an offscreen buffer and the copying the results to screen FragDance >From: "david besnard" <sup...@ho...> >To: mes...@li... >Subject: [Mesa3d-users] (no subject) >Date: Sat, 20 May 2000 02:34:30 PDT > >I have a problem when I try tu use hardware acceleration in a window >the programm run in fullscreen but more slower (30 image per second ) >whan I compute to fullscreen (it is 100 image per second) >I have a voodoo3 > > >________________________________________________________________________ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > >_______________________________________________ >Mesa3d-users mailing list >Mes...@li... >http://lists.sourceforge.net/mailman/listinfo/mesa3d-users ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com |
From: Entelin H. <ml...@ho...> - 2001-11-26 05:36:12
|
hmm interesting, this first list is with nvidia's libGL.so.1.0.1541 it dident turn up any results. However...... ------------------------------------------------------------------ entelin@entelin:/usr/lib$ ll *libGL* lrwxr-xr-x 1 root root 17 Nov 25 13:24 libGL.so -> libGL.so.1.0.1541 lrwxr-xr-x 1 root root 17 Nov 25 13:24 libGL.so.1 -> libGL.so.1.0.1541 -rwxr-xr-x 1 root root 312964 Nov 25 13:24 libGL.so.1.0.1541 -rwxr-xr-x 1 root root 795 Nov 25 10:01 libGLU.la lrwxr-xr-x 1 root root 17 Nov 25 10:01 libGLU.so -> libGLU.so.1.3.400 lrwxr-xr-x 1 root root 17 Nov 24 22:19 libGLU.so.0 -> libGLU.so.0.1.350 -rwxr-xr-x 1 root root 254887 Nov 24 22:19 libGLU.so.0.1.350 lrwxr-xr-x 1 root root 17 Nov 25 10:01 libGLU.so.1 -> libGLU.so.1.3.400 -rwxr-xr-x 1 root root 1443622 Nov 24 23:09 libGLU.so.1.3.350 -rwxr-xr-x 1 root root 1476410 Nov 25 10:01 libGLU.so.1.3.400 lrwxr-xr-x 1 root root 21 Nov 25 13:24 libGLcore.so.1 -> libGLcore.so.1.0.1541 -rwxr-xr-x 1 root root 3414576 Nov 25 13:24 libGLcore.so.1.0.1541 entelin@entelin:/usr/lib$ nm libGLcore.so.1 | grep SGIX nm: libGLcore.so.1: no symbols entelin@entelin:/usr/lib$ nm libGL.so.1 | grep SGIX nm: libGL.so.1: no symbols entelin@entelin:/usr/lib$ ---------------------------------------------------------------------- ..... when replaced with the mesa copy it turns up with results.... ---------------------------------------------------------------------- entelin@entelin:/usr/lib$ ll *libGL* -rwxr-xr-x 1 root root 743 Nov 25 22:12 libGL.la lrwxr-xr-x 1 root root 16 Nov 25 22:12 libGL.so -> libGL.so.1.3.400 lrwxr-xr-x 1 root root 16 Nov 25 22:12 libGL.so.1 -> libGL.so.1.3.400 -rwxr-xr-x 1 root root 312964 Nov 25 13:24 libGL.so.1.0.1541 -rwxr-xr-x 1 root root 4969042 Nov 25 22:12 libGL.so.1.3.400 -rwxr-xr-x 1 root root 795 Nov 25 22:12 libGLU.la lrwxr-xr-x 1 root root 17 Nov 25 22:12 libGLU.so -> libGLU.so.1.3.400 lrwxr-xr-x 1 root root 17 Nov 24 22:19 libGLU.so.0 -> libGLU.so.0.1.350 -rwxr-xr-x 1 root root 254887 Nov 24 22:19 libGLU.so.0.1.350 lrwxr-xr-x 1 root root 17 Nov 25 22:12 libGLU.so.1 -> libGLU.so.1.3.400 -rwxr-xr-x 1 root root 1443622 Nov 24 23:09 libGLU.so.1.3.350 -rwxr-xr-x 1 root root 1476410 Nov 25 22:12 libGLU.so.1.3.400 lrwxr-xr-x 1 root root 21 Nov 25 13:24 libGLcore.so.1 -> libGLcore.so.1.0.1541 -rwxr-xr-x 1 root root 3414576 Nov 25 13:24 libGLcore.so.1.0.1541 entelin@entelin:/usr/lib$ nm libGL.so.1 | grep glXBindChannelToWindowSGIX 0000000000180124 t Fake_glXBindChannelToWindowSGIX 000000000017d788 T glXBindChannelToWindowSGIX ------------------------------------------------------------------------- I went through all of the undefined ref's listed below to make shure they were all there and they all were each listed exactly as above, among many others. However osg still fails in the same way. Here is the command (I think) in the makefile that generates it if it is helpfull. g++ -O2 -W -Wall -L/usr/X11R6/lib -L../../../lib sgv.o -losgGLUT -losgUtil -losgDB -losg -lglut -lGLU -lGL -lm -lXmu -lX11 -lXi -o ../../../bin/sgv So how do I tell it to find them in that other library ?? -------------------------------------------------------------------------- >From: Brian Paul <bri...@ya...> >To: Entelin Hightree <ml...@ho...> >CC: mes...@li... >Subject: Re: [Mesa3d-users] (no subject) >Date: Sun, 25 Nov 2001 13:57:18 -0700 > >Entelin Hightree wrote: > > > > I am having some problems compiling some apps (namely Open Scene Graph) > > my platform is linux 2.4.10, slackware 8.0, mesa 4.0 > > > > On compiling osg I get this > > /usr/lib/libglut.so: undefined reference to `glXBindChannelToWindowSGIX' > > /usr/lib/libglut.so: undefined reference to >`glXCreateContextWithConfigSGIX' > > /usr/lib/libglut.so: undefined reference to `glXGetFBConfigAttribSGIX' > > /usr/lib/libglut.so: undefined reference to `glXQueryChannelDeltasSGIX' > > /usr/lib/libglut.so: undefined reference to `glXChannelRectSyncSGIX' > > /usr/lib/libglut.so: undefined reference to `glXChannelRectSGIX' > > /usr/lib/libglut.so: undefined reference to `glXQueryChannelRectSGIX' > > /usr/lib/libglut.so: undefined reference to >`glXGetFBConfigFromVisualSGIX' > > collect2: ld returned 1 exit status > >Can you show the command and its arguments which is producing this error? > > > > an nm on libglut says that they are indeed missing I have tried mesa 3.5 >and > > 4.0 as well as sgi's glut and they all return this. ?? Does anyone know >how > > I can satisfy this ?. > > > > entelin@entelin:/usr/lib$ nm libglut.so.3.7.0 | grep SGIX > > U glXBindChannelToWindowSGIX > > U glXChannelRectSGIX > > U glXChannelRectSyncSGIX > > U glXCreateContextWithConfigSGIX > > U glXGetFBConfigAttribSGIX > > U glXGetFBConfigFromVisualSGIX > > U glXQueryChannelDeltasSGIX > > U glXQueryChannelRectSGIX > > > > any help would be most.... helpful :) > >Run 'nm libGL.so.1' | grep SGIX' and see if those symbols are listed, but >with >a 'T' instead of 'U'. > >-Brian > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > > >_______________________________________________ >Mesa3d-users mailing list >Mes...@li... >https://lists.sourceforge.net/lists/listinfo/mesa3d-users _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp |
From: Brian P. <bri...@ya...> - 2001-11-26 21:08:49
|
Entelin Hightree wrote: > > hmm interesting, this first list is with nvidia's libGL.so.1.0.1541 it > dident turn up any results. However...... > > ------------------------------------------------------------------ > entelin@entelin:/usr/lib$ ll *libGL* > lrwxr-xr-x 1 root root 17 Nov 25 13:24 libGL.so -> > libGL.so.1.0.1541 > lrwxr-xr-x 1 root root 17 Nov 25 13:24 libGL.so.1 -> > libGL.so.1.0.1541 > -rwxr-xr-x 1 root root 312964 Nov 25 13:24 libGL.so.1.0.1541 > -rwxr-xr-x 1 root root 795 Nov 25 10:01 libGLU.la > lrwxr-xr-x 1 root root 17 Nov 25 10:01 libGLU.so -> > libGLU.so.1.3.400 > lrwxr-xr-x 1 root root 17 Nov 24 22:19 libGLU.so.0 -> > libGLU.so.0.1.350 > -rwxr-xr-x 1 root root 254887 Nov 24 22:19 libGLU.so.0.1.350 > lrwxr-xr-x 1 root root 17 Nov 25 10:01 libGLU.so.1 -> > libGLU.so.1.3.400 > -rwxr-xr-x 1 root root 1443622 Nov 24 23:09 libGLU.so.1.3.350 > -rwxr-xr-x 1 root root 1476410 Nov 25 10:01 libGLU.so.1.3.400 > lrwxr-xr-x 1 root root 21 Nov 25 13:24 libGLcore.so.1 -> > libGLcore.so.1.0.1541 > -rwxr-xr-x 1 root root 3414576 Nov 25 13:24 > libGLcore.so.1.0.1541 > entelin@entelin:/usr/lib$ nm libGLcore.so.1 | grep SGIX > nm: libGLcore.so.1: no symbols > entelin@entelin:/usr/lib$ nm libGL.so.1 | grep SGIX > nm: libGL.so.1: no symbols > entelin@entelin:/usr/lib$ When 'nm' says there's no symbols in a library you can try using 'strings' instead to see what symbols it may or may not have. I don't believe NVIDIA's libGL has the functions that GLUT's looking for. > ---------------------------------------------------------------------- > > ..... when replaced with the mesa copy it turns up with results.... > > ---------------------------------------------------------------------- > entelin@entelin:/usr/lib$ ll *libGL* > -rwxr-xr-x 1 root root 743 Nov 25 22:12 libGL.la > lrwxr-xr-x 1 root root 16 Nov 25 22:12 libGL.so -> > libGL.so.1.3.400 > lrwxr-xr-x 1 root root 16 Nov 25 22:12 libGL.so.1 -> > libGL.so.1.3.400 > -rwxr-xr-x 1 root root 312964 Nov 25 13:24 libGL.so.1.0.1541 > -rwxr-xr-x 1 root root 4969042 Nov 25 22:12 libGL.so.1.3.400 > -rwxr-xr-x 1 root root 795 Nov 25 22:12 libGLU.la > lrwxr-xr-x 1 root root 17 Nov 25 22:12 libGLU.so -> > libGLU.so.1.3.400 > lrwxr-xr-x 1 root root 17 Nov 24 22:19 libGLU.so.0 -> > libGLU.so.0.1.350 > -rwxr-xr-x 1 root root 254887 Nov 24 22:19 libGLU.so.0.1.350 > lrwxr-xr-x 1 root root 17 Nov 25 22:12 libGLU.so.1 -> > libGLU.so.1.3.400 > -rwxr-xr-x 1 root root 1443622 Nov 24 23:09 libGLU.so.1.3.350 > -rwxr-xr-x 1 root root 1476410 Nov 25 22:12 libGLU.so.1.3.400 > lrwxr-xr-x 1 root root 21 Nov 25 13:24 libGLcore.so.1 -> > libGLcore.so.1.0.1541 > -rwxr-xr-x 1 root root 3414576 Nov 25 13:24 > libGLcore.so.1.0.1541 > entelin@entelin:/usr/lib$ nm libGL.so.1 | grep glXBindChannelToWindowSGIX > 0000000000180124 t Fake_glXBindChannelToWindowSGIX > 000000000017d788 T glXBindChannelToWindowSGIX > ------------------------------------------------------------------------- Yes, Mesa's libGL has stub (no-op) functions for these and other SGI extensions. > I went through all of the undefined ref's listed below to make shure they > were all there and they all were each listed exactly as above, among many > others. However osg still fails in the same way. Here is the command (I > think) in the makefile that generates it if it is helpfull. > > g++ -O2 -W -Wall -L/usr/X11R6/lib -L../../../lib sgv.o -losgGLUT > -losgUtil -losgDB -losg -lglut -lGLU -lGL -lm -lXmu -lX11 -lXi -o > ../../../bin/sgv > > So how do I tell it to find them in that other library ?? You can't. You'd have to rebuild GLUT so that it doesn't try to use those extension functions. A temporary work-around is to add dummies for those functions to your application. I.e. add this in your app: int glXBindChannelToWindowSGIX(void) { return 0; } There may be other builds of GLUT on the net that don't need those extension functions. I'm updating GLUT to use the glXGetProcAddressARB() function to get pointers to extension functions, instead of referencing them directly. That should solve this problem. Look for it in Mesa 4.0.1. -Brian _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: Meilyr W. <mei...@ho...> - 2002-06-19 09:36:33
|
Hello again Im using linux red hat version 6.2 kernel version 2.2.19 Ive checked errno.h, there is no definition for EINTR there. What would you suggest? Many thanks for your help Meilyr > >Meilyr Wyn wrote: >>Thanks Brian for the reply >> >>I have sorted out the header files problems. Now i get the following >>error message when compiling GLUT: >> >>glut_event.c: In function `interruptibleXNextEvent': >>glut_event.c:328: `EINTR' undeclared (first use in this function) >>glut_event.c:926: `EINTR' undeclared (first use in this function) >>make[2]: *** [glut_event.o] Error 1 >> >>Any suggestions would be very much appreciated. > >EINTR is a standard Unix error token (usually defined in >/usr/include/errno.h). > >Which OS are you using? > >-Brian > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. |
From: Stephen J B. <sj...@li...> - 2002-06-19 12:23:29
|
On Wed, 19 Jun 2002, Meilyr Wyn wrote: > Im using linux red hat version 6.2 > kernel version 2.2.19 > > Ive checked errno.h, there is no definition for EINTR there. It must be there somewhere - *way* too many UNIX programs rely on it - including many of mine that I *know* are running under RH6.2. > What would you suggest? Grep for it of course... grep EINTR /usr/include/* grep EINTR /usr/include/*/* grep EINTR /usr/include/*/*/* ... ...until you find it. On my SuSE system, it's defined in /usr/include/asm/errno.h You should include <errno.h> ... ...which includes <bits/errno.h> ...which includes <linux/errno.h> ...which includes <asm/errno.h> ...which #define's EINTR ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |
From: Stephen J B. <sj...@ht...> - 2000-05-22 13:35:10
|
On Sat, 20 May 2000, FragDance Galore wrote: > That is because (as I understand it) the windowed mode on a Voodoo3 is a > hack. Voodoo3 is designed to run in fullscreen, and Mesa allows Voodoo3 to > run in a window by first rendering to an offscreen buffer and the copying > the results to screen That's true for Voodoo-1 and -2 but a Voodoo-3 should be able to do this directly without the Mesa hack. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@ht... http://www.hti.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
From: Brian P. <br...@pr...> - 2000-05-22 14:08:49
|
Stephen J Baker wrote: > > On Sat, 20 May 2000, FragDance Galore wrote: > > > That is because (as I understand it) the windowed mode on a Voodoo3 is a > > hack. Voodoo3 is designed to run in fullscreen, and Mesa allows Voodoo3 to > > run in a window by first rendering to an offscreen buffer and the copying > > the results to screen > > That's true for Voodoo-1 and -2 but a Voodoo-3 should be able to do this > directly without the Mesa hack. When using XFree86 4.0 and the DRI, of course. -Brian |