Testing/mesademos
I'm trying to compile mesademos on a testing box. The only variation so far is that I'm using mga_drv.o and mga_hal_drv.o from Matrox; I haven't even configured DRI on my G450 yet. My problem is here: pugelist:/usr/share/doc/mesademos/demos# make linux make -f Makefile.X11 targets \ "GL_LIB = libGL.a" \ "GLU_LIB = libGLU.a" \ "GLUT_LIB = libglut.a" \ "GLW_LIB = libGLw.a" \ "CC = gcc" \ "CFLAGS = -O3 -funroll-loops -ansi -pedantic -ffast-math -D_SVID_SOURCE -D_BSD_SOURCE -DSHM -I/usr/X11R6/include" \ "MAKELIB = ../bin/mklib.ar-ruv" \ "XLIBS = -L/usr/X11R6/lib -lX11 -lXext -lXmu -lXt -lXi -lSM -lICE -lm" make[1]: Entering directory `/usr/share/doc/mesademos/demos' gcc -I../include -O3 -funroll-loops -ansi -pedantic -ffast-math -D_SVID_SOURCE -D_BSD_SOURCE -DSHM -I/usr/X11R6/include osdemo.c -L../lib -lglut -lGLU -lGL -L/usr/X11R6/lib -lX11 -lXext -lXmu -lXt -lXi -lSM -lICE -lm -o osdemo /tmp/ccEMh1hu.o: In function `main': /tmp/ccEMh1hu.o(.text+0x32a): undefined reference to `OSMesaCreateContext' /tmp/ccEMh1hu.o(.text+0x35c): undefined reference to `OSMesaMakeCurrent' /tmp/ccEMh1hu.o(.text+0x4f5): undefined reference to `OSMesaDestroyContext' collect2: ld returned 1 exit status make[1]: *** [osdemo] Error 1 make[1]: Leaving directory `/usr/share/doc/mesademos/demos' make: *** [linux] Error 2 There are other bins in the mesademos/demos/ directory, which `make clean' does not get rid of (and there's no target `distclean'). This, I assume, is a problem with the upstream Makefile, not Branden's customizations. Aside from the does-not-compile issue, I also wonder if it's really so necessary to keep each directory under usr/share/doc/mesademos/ a tarball after installation. It's pretty clear that if someone installs the mesademos package, they want to run the demos. I understand shipping in source-only; that makes a lot of sense to a DRI user like myself. But compressed? The uncompressed trees take well less than 4MB, and it seems more than a little silly to make someone who is building the demos manually unpack them. Against whom do I file my d-n-c bug and my wishlist bug, respectively? -- -=|JP|=-"This space intentionally left blank." Jon Pennington | Debian 2.4 -o) [EMAIL PROTECTED] | Auto Enthusiast/\\ Kansas City, MO, USA| Proud Husband and Father _\_V -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/mesademos
Jon Pennington [EMAIL PROTECTED] writes: /tmp/ccEMh1hu.o(.text+0x32a): undefined reference to `OSMesaCreateContext' /tmp/ccEMh1hu.o(.text+0x35c): undefined reference to `OSMesaMakeCurrent' /tmp/ccEMh1hu.o(.text+0x4f5): undefined reference to `OSMesaDestroyContext' Hmmm... please submit this as a bug, there's a -lOSMesa missing. I'm going to fix the makefiles, so I'm going to stumble across this, probably. There are other bins in the mesademos/demos/ directory, which `make clean' does not get rid of (and there's no target `distclean'). This, I assume, is a problem with the upstream Makefile, not Branden's customizations. Branden doesn't maintain mesademos. /me waves Aside from the does-not-compile issue, I also wonder if it's really so necessary to keep each directory under usr/share/doc/mesademos/ a tarball after installation. It's pretty clear that if someone installs the mesademos package, they want to run the demos. Oh, is it? For me the demos are more valuable as source code, since only a fraction of them are interesting from a end-user's point of view. I understand shipping in source-only; that makes a lot of sense to a DRI user like myself The demos themselves are not tied to the Direct Rendering Infrastructure. They are OpenGL demos, and only a handful are specific to Mesa. All of them run with software rendering, now that the glide-specific demos are no longer being shipped. But compressed? The uncompressed trees take well less than 4MB, and it seems more than a little silly to make someone who is building the demos manually unpack them. You mean tarred. Like I said, IMO in this case source is more important than binaries. I considered shipping everything as single files, in ../mesademos/examples/ or something like that, but then I would have to compress the individual files (c.f. Policy), which is no better than having to unpack the tarred sources. Against whom do I file my d-n-c bug and my wishlist bug, respectively? d-n-c? You lost me. Oh, does-not-compile. I hope you don't mean that as in 'serious' because it will be automatically downgraded to normal once I get it. mesademos, on both accounts. -- Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing/mesademos
On Fri, Apr 06, 2001 at 10:32:16PM +0200, Marcelo E. Magallon wrote: Jon Pennington [EMAIL PROTECTED] writes: /tmp/ccEMh1hu.o(.text+0x32a): undefined reference to `OSMesaCreateContext' /tmp/ccEMh1hu.o(.text+0x35c): undefined reference to `OSMesaMakeCurrent' /tmp/ccEMh1hu.o(.text+0x4f5): undefined reference to `OSMesaDestroyContext' Hmmm... please submit this as a bug, there's a -lOSMesa missing. I'm going to fix the makefiles, so I'm going to stumble across this, probably. On it's way. There are other bins in the mesademos/demos/ directory, which `make clean' does not get rid of (and there's no target `distclean'). This, I assume, is a problem with the upstream Makefile, not Branden's customizations. Branden doesn't maintain mesademos. /me waves Sorry, I was reading the Maintainer: line from xlibosmesa-dev when I wrote this. My apologies for the confusion I've caused. Aside from the does-not-compile issue, I also wonder if it's really so necessary to keep each directory under usr/share/doc/mesademos/ a tarball after installation. It's pretty clear that if someone installs the mesademos package, they want to run the demos. Oh, is it? For me the demos are more valuable as source code, since only a fraction of them are interesting from a end-user's point of view. Absolutely! This is what I meant to say. Shipping the mesademos package in binary form does not make any sense. There are too many libGL implementations floating around for that. But compressed? The uncompressed trees take well less than 4MB, and it seems more than a little silly to make someone who is building the demos manually unpack them. You mean tarred. Like I said, IMO in this case source is more important than binaries. I said that too :) I considered shipping everything as single files, in ../mesademos/examples/ or something like that, but then I would have to compress the individual files (c.f. Policy), which is no better than having to unpack the tarred sources. Why compress them at all? dpkg compresses them anyway; dpkg'ing a compressed file of any kind is redundant. My question is, "Why must you tar them up at all." My logic is, "I asked for the sources; dpkg compresses anything you feed to it; compressing the sources before being added to a deb is a waste of time, and a waste of my time after I install the package; I expect packages to be usable almost immediately after installing (aside from editing configuration files, and in this case, a bit of mild compiling, NOT untarring a package-within-a-package)." Against whom do I file my d-n-c bug and my wishlist bug, respectively? d-n-c? You lost me. Oh, does-not-compile. I hope you don't mean that as in 'serious' because it will be automatically downgraded to normal once I get it. Thanks for your time :) -- -=|JP|=-"This space intentionally left blank." Jon Pennington | Debian 2.4 -o) [EMAIL PROTECTED] | Auto Enthusiast/\\ Kansas City, MO, USA| Proud Husband and Father _\_V -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dri and shared memory
Hello, I have installed the new dri packages, and at last I have 3gl, I am getting ~100 fps with the evas_test on my g400. but I do have on problem. With enlightenment and imlib1 it can't seem to detect the shared memory, which also seems to cause the latest version of gnome panel crash as well. Can anyone give me any ideas on how to resolve this problem -- Gordon Heydon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
XFree 4.0.2-13 ; issues with SiS 6326
Dear list, I just had to buy a new system (the old one had a dying MB ...) and got something with a SiS 6326, which is giving me troubles with xfree 4.0.2-13 as shipped in unstable (listed in order of discovery) : - No autodetection of mouse protocol and port (I had to put it manually in place), neither by xf86cfg nor X -configure. - A big gray striped block instead of a mouse pointer, unless I use SoftwareCursor - Incorrect display of some Web page background in NS 4.7 (I get a red-blue chexker instead of an uniform shade, making the text unreadable) unless I use NoAccel - No startup if I ask for a 24 bit deep 1280x1024 display ; 16-bit deep display works fine. - Display is slow (probably due to the NoAccel option I have to use ...). Does this rings a bell among X developpers ? I read on www.xfree.org that somme issues with SiS driver have been fixed in 4.0.3. Is there an ETA for it in debian/unstable ? Do you have some idea of how I could work around in the meantime ? The sis manpage isn't very helpful, to say the least ... Last but not least : should I submit a formal bug report ? if so, about what package ? Emmanuel Charpentier PS : It seems that I can get a replacement ATI RagePro for not much more. Should I dive for that, or be pigheaded about the SiS ? -- Emmanuel CharpentierTel : +33-01 40 27 35 98 Secrétariat scientifique du CEDIT Fax : +33-01 40 27 55 65 Direction de la Politique Médicale // Assistance Publique - Hôpitaux de Paris 3, Avenue Victoria // F-75004 Paris /// France -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Testing/mesademos
I'm trying to compile mesademos on a testing box. The only variation so far is that I'm using mga_drv.o and mga_hal_drv.o from Matrox; I haven't even configured DRI on my G450 yet. My problem is here: pugelist:/usr/share/doc/mesademos/demos# make linux make -f Makefile.X11 targets \ GL_LIB = libGL.a \ GLU_LIB = libGLU.a \ GLUT_LIB = libglut.a \ GLW_LIB = libGLw.a \ CC = gcc \ CFLAGS = -O3 -funroll-loops -ansi -pedantic -ffast-math -D_SVID_SOURCE -D_BSD_SOURCE -DSHM -I/usr/X11R6/include \ MAKELIB = ../bin/mklib.ar-ruv \ XLIBS = -L/usr/X11R6/lib -lX11 -lXext -lXmu -lXt -lXi -lSM -lICE -lm make[1]: Entering directory `/usr/share/doc/mesademos/demos' gcc -I../include -O3 -funroll-loops -ansi -pedantic -ffast-math -D_SVID_SOURCE -D_BSD_SOURCE -DSHM -I/usr/X11R6/include osdemo.c -L../lib -lglut -lGLU -lGL -L/usr/X11R6/lib -lX11 -lXext -lXmu -lXt -lXi -lSM -lICE -lm -o osdemo /tmp/ccEMh1hu.o: In function `main': /tmp/ccEMh1hu.o(.text+0x32a): undefined reference to `OSMesaCreateContext' /tmp/ccEMh1hu.o(.text+0x35c): undefined reference to `OSMesaMakeCurrent' /tmp/ccEMh1hu.o(.text+0x4f5): undefined reference to `OSMesaDestroyContext' collect2: ld returned 1 exit status make[1]: *** [osdemo] Error 1 make[1]: Leaving directory `/usr/share/doc/mesademos/demos' make: *** [linux] Error 2 There are other bins in the mesademos/demos/ directory, which `make clean' does not get rid of (and there's no target `distclean'). This, I assume, is a problem with the upstream Makefile, not Branden's customizations. Aside from the does-not-compile issue, I also wonder if it's really so necessary to keep each directory under usr/share/doc/mesademos/ a tarball after installation. It's pretty clear that if someone installs the mesademos package, they want to run the demos. I understand shipping in source-only; that makes a lot of sense to a DRI user like myself. But compressed? The uncompressed trees take well less than 4MB, and it seems more than a little silly to make someone who is building the demos manually unpack them. Against whom do I file my d-n-c bug and my wishlist bug, respectively? -- -=|JP|=-This space intentionally left blank. Jon Pennington | Debian 2.4 -o) [EMAIL PROTECTED] | Auto Enthusiast/\\ Kansas City, MO, USA| Proud Husband and Father _\_V
Re: Testing/mesademos
Jon Pennington [EMAIL PROTECTED] writes: /tmp/ccEMh1hu.o(.text+0x32a): undefined reference to `OSMesaCreateContext' /tmp/ccEMh1hu.o(.text+0x35c): undefined reference to `OSMesaMakeCurrent' /tmp/ccEMh1hu.o(.text+0x4f5): undefined reference to `OSMesaDestroyContext' Hmmm... please submit this as a bug, there's a -lOSMesa missing. I'm going to fix the makefiles, so I'm going to stumble across this, probably. There are other bins in the mesademos/demos/ directory, which `make clean' does not get rid of (and there's no target `distclean'). This, I assume, is a problem with the upstream Makefile, not Branden's customizations. Branden doesn't maintain mesademos. /me waves Aside from the does-not-compile issue, I also wonder if it's really so necessary to keep each directory under usr/share/doc/mesademos/ a tarball after installation. It's pretty clear that if someone installs the mesademos package, they want to run the demos. Oh, is it? For me the demos are more valuable as source code, since only a fraction of them are interesting from a end-user's point of view. I understand shipping in source-only; that makes a lot of sense to a DRI user like myself The demos themselves are not tied to the Direct Rendering Infrastructure. They are OpenGL demos, and only a handful are specific to Mesa. All of them run with software rendering, now that the glide-specific demos are no longer being shipped. But compressed? The uncompressed trees take well less than 4MB, and it seems more than a little silly to make someone who is building the demos manually unpack them. You mean tarred. Like I said, IMO in this case source is more important than binaries. I considered shipping everything as single files, in ../mesademos/examples/ or something like that, but then I would have to compress the individual files (c.f. Policy), which is no better than having to unpack the tarred sources. Against whom do I file my d-n-c bug and my wishlist bug, respectively? d-n-c? You lost me. Oh, does-not-compile. I hope you don't mean that as in 'serious' because it will be automatically downgraded to normal once I get it. mesademos, on both accounts. -- Marcelo
Re: Testing/mesademos
On Fri, Apr 06, 2001 at 10:32:16PM +0200, Marcelo E. Magallon wrote: Jon Pennington [EMAIL PROTECTED] writes: /tmp/ccEMh1hu.o(.text+0x32a): undefined reference to `OSMesaCreateContext' /tmp/ccEMh1hu.o(.text+0x35c): undefined reference to `OSMesaMakeCurrent' /tmp/ccEMh1hu.o(.text+0x4f5): undefined reference to `OSMesaDestroyContext' Hmmm... please submit this as a bug, there's a -lOSMesa missing. I'm going to fix the makefiles, so I'm going to stumble across this, probably. On it's way. There are other bins in the mesademos/demos/ directory, which `make clean' does not get rid of (and there's no target `distclean'). This, I assume, is a problem with the upstream Makefile, not Branden's customizations. Branden doesn't maintain mesademos. /me waves Sorry, I was reading the Maintainer: line from xlibosmesa-dev when I wrote this. My apologies for the confusion I've caused. Aside from the does-not-compile issue, I also wonder if it's really so necessary to keep each directory under usr/share/doc/mesademos/ a tarball after installation. It's pretty clear that if someone installs the mesademos package, they want to run the demos. Oh, is it? For me the demos are more valuable as source code, since only a fraction of them are interesting from a end-user's point of view. Absolutely! This is what I meant to say. Shipping the mesademos package in binary form does not make any sense. There are too many libGL implementations floating around for that. But compressed? The uncompressed trees take well less than 4MB, and it seems more than a little silly to make someone who is building the demos manually unpack them. You mean tarred. Like I said, IMO in this case source is more important than binaries. I said that too :) I considered shipping everything as single files, in ../mesademos/examples/ or something like that, but then I would have to compress the individual files (c.f. Policy), which is no better than having to unpack the tarred sources. Why compress them at all? dpkg compresses them anyway; dpkg'ing a compressed file of any kind is redundant. My question is, Why must you tar them up at all. My logic is, I asked for the sources; dpkg compresses anything you feed to it; compressing the sources before being added to a deb is a waste of time, and a waste of my time after I install the package; I expect packages to be usable almost immediately after installing (aside from editing configuration files, and in this case, a bit of mild compiling, NOT untarring a package-within-a-package). Against whom do I file my d-n-c bug and my wishlist bug, respectively? d-n-c? You lost me. Oh, does-not-compile. I hope you don't mean that as in 'serious' because it will be automatically downgraded to normal once I get it. Thanks for your time :) -- -=|JP|=-This space intentionally left blank. Jon Pennington | Debian 2.4 -o) [EMAIL PROTECTED] | Auto Enthusiast/\\ Kansas City, MO, USA| Proud Husband and Father _\_V
