Re: XFree86, Mesa, Debian, and libGLU revisited
>> Sven LUTHER <[EMAIL PROTECTED]> writes: > There are no licence issues i think, as the licence of libLGU is > compatible with the xfree licence. Of course it compatible, this is the XFree86 license, almost anything is compatible with it. The question is if the Free License B is ok according to the DFSG. Marcelo
Re: LibGLU.so.1
Matt, I ran into this same problem. I easily solved it by installing the mesa itself. For some strange reason, that library doesn't necessarily register itself with ldconfig. ** Derek J Witt ** * Email: mailto:[EMAIL PROTECTED] * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown **
Re: LibGLU.so.1
On Mon, 18 Sep 2000, Matthew Sackman wrote: > Hay all. > > I've just upgraded to the XFree86 4.0.1 phase 2v6. I stripped out my > 3.3.6 installation first and fetched everything ok with apt-get and > dselect. > > However, when running most games, and KDE (version 2 beta4), the > application will refuse to start, giving an error message: > > error in loading shared libraries: libGLU.so.1: cannot open shared object > file: No such file or directory I just did the same thing this morning :) the problem is that libqt is linked to libGLU the quick work around is to remove libGLU when creating libqt if you have the qt source tree, you do cd $QTDIR/src edit Makefile and remove -lGLU rm $QTDIR/lib/* make if you don't have the qt tree then apt-get source is your friend after that everything works except the screensaver(or any apps depending on GLU) which need GL C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243| I respect faith, but doubt is Cambridge MA 02139 | what gives you an education. Tel (Office) : (00 1) (617) 253 0229 | -- Wilson Mizner Fax (Office) : (00 1) (617) 258 8559 | http://augustine.mit.edu/~prudhomm | Following the hacker spirit
Re: XFree86, Mesa, Debian, and libGLU revisited
Branden Robinson wrote: > > [Sorry for the CC, Brian, I just wanted to make sure that people who know > better than I can stop me before I do anything stupid] > > On Sun, Sep 17, 2000 at 03:01:53PM +0200, Harald Dunkel wrote: > > I'm running XFree 4.0.1 for several days on my PC at home now. > > There seemed to be no serious problems. > > > > But on building some OpenGL applications (the OpenGL hacks of > > xscreensaver) I recognized that the GLU library is gone. Before > > the update libGLU.so could be found in the old mesag3 package. > > A similar problem exists for the xlibgl-dev package: The GLU > > header files are gone. > > > > Shouldn't be GLU included in xlibgl1/xlibgl-dev to provide true > > compatibility to Mesa? > > Yes, but here's the problem: > > The XFree86 source tree, which contains Mesa (libGL and libOSMesa, the > off-screen rendering library), does *not* contain libGLU. I don't honestly > know why this choice was originally made (I get the impression it has > something do with libGLU being written in C++ -- no other part of the > XFree86 source distribution is). > > However, a consensus has formed of late among the XFree86 developers, in > conjunction with Brian Paul (the mastermind of the Mesa project), that > libGLU should be shipped, built and installed with the rest of Mesa as part > of the XFree86 distribution. I've corresponded with Brian on this point, > and he suggests that the 3 libraries, libGL, libGLU, and libOSMesa, be > shipped in one package. I see no compelling reason to do otherwise. > > So: > > + xlibosmesa* and xlibgl* will merge into xlibmesa* in (probably) the next > XFree86 phase2 .deb release > + libGLU will become part of xlibmesa* as soon as upstream XFree86 makes it > available; I don't have a timeframe on this > + Mesa will continue to be maintained separately from XFree86 itself, > though I gather the only real difference will be that XFree86 will decide > based on its own needs when it takes snapshots from the Mesa CVS tree; I > don't gather that there is a real fork underway Right. > + Debian's Mesa packages will thus continue to be separately maintained, > for people who don't need the DRI drivers (I don't think there is any > functional difference between the official Mesa and XFree86 version of > Mesa if DRI is not available -- or not used -- with your video hardware) If you don't have 3D hardware or disable the DRI you can still use the software-based GLX renderer (which is based on Mesa). However, you can't access as many extensions using software GLX as with stand-alone Mesa. > + The off-screen rendering library, libOSMesa, is not yet available in the > Debian Mesa packages (last I checked); this should be remedied when an > official upstream version of Mesa is released with it (which I don't > think has happened yet) and when the Debian package maintainer then > releases it Right, I haven't made libOSMesa.so part of the regular, stand-alone Mesa disto, yet. > Here's the practical, important part: > > + In the meantime, users are going to have play games behind the back of > the packaging system to satisfy any program that requires libGLU: > > - retrieve the appropriate mesag3 .deb package for your architecture > - put it in a subdirectory of /tmp (not /tmp itself) > - dpkg-deb -x mesag3-glide2_3.2.1-1_i386.deb . > (or whatever the .deb is named) > - become root, and return to this directory if necessary > - cd usr/lib > - as root, cp *libGLU* /usr/lib > > People who need to compile against the libGLU headers can figure out the > analogous steps for mesag3-dev. > > Sorry about this kludgey situation -- it's life on the bleeding edge. It > will be rectified once the XFree86 sources are building libGLU. Yes. Putting GLU into XFree86 is underway. -Brian
LibGLU.so.1
Hay all. I've just upgraded to the XFree86 4.0.1 phase 2v6. I stripped out my 3.3.6 installation first and fetched everything ok with apt-get and dselect. However, when running most games, and KDE (version 2 beta4), the application will refuse to start, giving an error message: error in loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory My GPU is an NVidia TNT2 M64, I've tried to install the new 0.9-5 drivers for it (though had problems: the source refused to compile for me, so I had to do an 'alien' on the RPMs for RedHat 6.1). However, this has not solved the problem, and I don't know how to. Does anyone know what I've done wrong or how I can fix this? Thanks, Matthew
Re: XFree86, Mesa, Debian, and libGLU revisited
>> Sven LUTHER <[EMAIL PROTECTED]> writes: > There are no licence issues i think, as the licence of libLGU is > compatible with the xfree licence. Of course it compatible, this is the XFree86 license, almost anything is compatible with it. The question is if the Free License B is ok according to the DFSG. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LibGLU.so.1
Matt, I ran into this same problem. I easily solved it by installing the mesa itself. For some strange reason, that library doesn't necessarily register itself with ldconfig. ** Derek J Witt ** * Email: mailto:[EMAIL PROTECTED] * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LibGLU.so.1
On Mon, 18 Sep 2000, Matthew Sackman wrote: > Hay all. > > I've just upgraded to the XFree86 4.0.1 phase 2v6. I stripped out my > 3.3.6 installation first and fetched everything ok with apt-get and > dselect. > > However, when running most games, and KDE (version 2 beta4), the > application will refuse to start, giving an error message: > > error in loading shared libraries: libGLU.so.1: cannot open shared object > file: No such file or directory I just did the same thing this morning :) the problem is that libqt is linked to libGLU the quick work around is to remove libGLU when creating libqt if you have the qt source tree, you do cd $QTDIR/src edit Makefile and remove -lGLU rm $QTDIR/lib/* make if you don't have the qt tree then apt-get source is your friend after that everything works except the screensaver(or any apps depending on GLU) which need GL C. -- Christophe Prud'homme | MIT, 77, Mass Ave, Rm 3-243| I respect faith, but doubt is Cambridge MA 02139 | what gives you an education. Tel (Office) : (00 1) (617) 253 0229 | -- Wilson Mizner Fax (Office) : (00 1) (617) 258 8559 | http://augustine.mit.edu/~prudhomm | Following the hacker spirit -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86, Mesa, Debian, and libGLU revisited
Branden Robinson wrote: > > [Sorry for the CC, Brian, I just wanted to make sure that people who know > better than I can stop me before I do anything stupid] > > On Sun, Sep 17, 2000 at 03:01:53PM +0200, Harald Dunkel wrote: > > I'm running XFree 4.0.1 for several days on my PC at home now. > > There seemed to be no serious problems. > > > > But on building some OpenGL applications (the OpenGL hacks of > > xscreensaver) I recognized that the GLU library is gone. Before > > the update libGLU.so could be found in the old mesag3 package. > > A similar problem exists for the xlibgl-dev package: The GLU > > header files are gone. > > > > Shouldn't be GLU included in xlibgl1/xlibgl-dev to provide true > > compatibility to Mesa? > > Yes, but here's the problem: > > The XFree86 source tree, which contains Mesa (libGL and libOSMesa, the > off-screen rendering library), does *not* contain libGLU. I don't honestly > know why this choice was originally made (I get the impression it has > something do with libGLU being written in C++ -- no other part of the > XFree86 source distribution is). > > However, a consensus has formed of late among the XFree86 developers, in > conjunction with Brian Paul (the mastermind of the Mesa project), that > libGLU should be shipped, built and installed with the rest of Mesa as part > of the XFree86 distribution. I've corresponded with Brian on this point, > and he suggests that the 3 libraries, libGL, libGLU, and libOSMesa, be > shipped in one package. I see no compelling reason to do otherwise. > > So: > > + xlibosmesa* and xlibgl* will merge into xlibmesa* in (probably) the next > XFree86 phase2 .deb release > + libGLU will become part of xlibmesa* as soon as upstream XFree86 makes it > available; I don't have a timeframe on this > + Mesa will continue to be maintained separately from XFree86 itself, > though I gather the only real difference will be that XFree86 will decide > based on its own needs when it takes snapshots from the Mesa CVS tree; I > don't gather that there is a real fork underway Right. > + Debian's Mesa packages will thus continue to be separately maintained, > for people who don't need the DRI drivers (I don't think there is any > functional difference between the official Mesa and XFree86 version of > Mesa if DRI is not available -- or not used -- with your video hardware) If you don't have 3D hardware or disable the DRI you can still use the software-based GLX renderer (which is based on Mesa). However, you can't access as many extensions using software GLX as with stand-alone Mesa. > + The off-screen rendering library, libOSMesa, is not yet available in the > Debian Mesa packages (last I checked); this should be remedied when an > official upstream version of Mesa is released with it (which I don't > think has happened yet) and when the Debian package maintainer then > releases it Right, I haven't made libOSMesa.so part of the regular, stand-alone Mesa disto, yet. > Here's the practical, important part: > > + In the meantime, users are going to have play games behind the back of > the packaging system to satisfy any program that requires libGLU: > > - retrieve the appropriate mesag3 .deb package for your architecture > - put it in a subdirectory of /tmp (not /tmp itself) > - dpkg-deb -x mesag3-glide2_3.2.1-1_i386.deb . > (or whatever the .deb is named) > - become root, and return to this directory if necessary > - cd usr/lib > - as root, cp *libGLU* /usr/lib > > People who need to compile against the libGLU headers can figure out the > analogous steps for mesag3-dev. > > Sorry about this kludgey situation -- it's life on the bleeding edge. It > will be rectified once the XFree86 sources are building libGLU. Yes. Putting GLU into XFree86 is underway. -Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
LibGLU.so.1
Hay all. I've just upgraded to the XFree86 4.0.1 phase 2v6. I stripped out my 3.3.6 installation first and fetched everything ok with apt-get and dselect. However, when running most games, and KDE (version 2 beta4), the application will refuse to start, giving an error message: error in loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory My GPU is an NVidia TNT2 M64, I've tried to install the new 0.9-5 drivers for it (though had problems: the source refused to compile for me, so I had to do an 'alien' on the RPMs for RedHat 6.1). However, this has not solved the problem, and I don't know how to. Does anyone know what I've done wrong or how I can fix this? Thanks, Matthew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
TDFX and DRI
Is there an existing `NOWTO' for setting up the DRM and DRI modules for 3Dfx Voodoo3/Banshee products? The DRM must be built against your current kernel source tree, and it's the biggest headache so far. -- -=|JP|=-"Why, oh, why didn't I take the blue pill?" Jon Pennington| Atipa Linux Solutions -o) [EMAIL PROTECTED] | http://www.atipa.com/\\ Kansas City, MO, USA | 816-595-3000 x1550 _\_V 6D04 39E0 CAE9 9ADA 2CA3 2EBE 898A 6C37 CA1E A29C
TDFX and DRI
Is there an existing `NOWTO' for setting up the DRM and DRI modules for 3Dfx Voodoo3/Banshee products? The DRM must be built against your current kernel source tree, and it's the biggest headache so far. -- -=|JP|=-"Why, oh, why didn't I take the blue pill?" Jon Pennington| Atipa Linux Solutions -o) [EMAIL PROTECTED] | http://www.atipa.com/\\ Kansas City, MO, USA | 816-595-3000 x1550 _\_V 6D04 39E0 CAE9 9ADA 2CA3 2EBE 898A 6C37 CA1E A29C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPMS
Seth R Arnold spake thus: > In addition, having all three timeout values be the same *may* be > causing problems. Actually, with "xset dpms 1 1 1" and Simon's line in XF86Config, the screen blanks after 1 second, and then turns itself off after ~10 seconds. With more sane values, like 1200, things work perfectly. Øystein
Re: XFree86, Mesa, Debian, and libGLU revisited
On Mon, Sep 18, 2000 at 08:51:29AM +0200, Marcelo E. Magallon wrote: > Hi, > > sorry for getting in the middle of the conversation... > > >> Branden Robinson <[EMAIL PROTECTED]> writes: > > > The XFree86 source tree, which contains Mesa (libGL and libOSMesa, > > the off-screen rendering library), does *not* contain libGLU. I > > don't honestly know why this choice was originally made (I get the > > impression it has something do with libGLU being written in C++ -- > > no other part of the XFree86 source distribution is). > > Brian stated some months ago (and again last week) he wants to retire > the libGLU code from Mesa and use the SGI's Sample Implementation > code instead. What you say seems to indicate he changed his mind. There was some discution on the xfree mailing list about including the SGI version of libGLU (maybe even already in CVS as i remember seeing a patch submition regarding it on the mailing list). The main problem is that the SGI version is C++, and not C, which can causes compatibility problems with regard the various C++ compilers that Xfree uses. There are no licence issues i think, as the licence of libLGU is compatible with the xfree licence. Friendly, Sven LUTHER
Re: DPMS
* Simon Kongshoj <[EMAIL PROTECTED]> [000918 02:09]: > > With the XFree 4.x-packages, this no longer works - the screen just goes > > blank, but does not power down. Is this a known bug, and is there a > > workaround? > > You need to activate DPMS explicitly in the XF86Config file to get > DPMS. IIRC, you need a line called 'Option"DPMS"' in the Monitor > section. In addition, having all three timeout values be the same *may* be causing problems. In a related issue, does anyone have dual-head DPMS working? My G400 max only powers down the primary monitor at the requested time interval. Option "DPMS" is specified once for each monitor. Thanks. :) -- Seth Arnold | http://www.willamette.edu/~sarnold/
Re: DPMS
Seth R Arnold spake thus: > In addition, having all three timeout values be the same *may* be > causing problems. Actually, with "xset dpms 1 1 1" and Simon's line in XF86Config, the screen blanks after 1 second, and then turns itself off after ~10 seconds. With more sane values, like 1200, things work perfectly. Øystein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86, Mesa, Debian, and libGLU revisited
On Mon, Sep 18, 2000 at 08:51:29AM +0200, Marcelo E. Magallon wrote: > Hi, > > sorry for getting in the middle of the conversation... > > >> Branden Robinson <[EMAIL PROTECTED]> writes: > > > The XFree86 source tree, which contains Mesa (libGL and libOSMesa, > > the off-screen rendering library), does *not* contain libGLU. I > > don't honestly know why this choice was originally made (I get the > > impression it has something do with libGLU being written in C++ -- > > no other part of the XFree86 source distribution is). > > Brian stated some months ago (and again last week) he wants to retire > the libGLU code from Mesa and use the SGI's Sample Implementation > code instead. What you say seems to indicate he changed his mind. There was some discution on the xfree mailing list about including the SGI version of libGLU (maybe even already in CVS as i remember seeing a patch submition regarding it on the mailing list). The main problem is that the SGI version is C++, and not C, which can causes compatibility problems with regard the various C++ compilers that Xfree uses. There are no licence issues i think, as the licence of libLGU is compatible with the xfree licence. Friendly, Sven LUTHER -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPMS
* Simon Kongshoj <[EMAIL PROTECTED]> [000918 02:09]: > > With the XFree 4.x-packages, this no longer works - the screen just goes > > blank, but does not power down. Is this a known bug, and is there a > > workaround? > > You need to activate DPMS explicitly in the XF86Config file to get > DPMS. IIRC, you need a line called 'Option"DPMS"' in the Monitor > section. In addition, having all three timeout values be the same *may* be causing problems. In a related issue, does anyone have dual-head DPMS working? My G400 max only powers down the primary monitor at the requested time interval. Option "DPMS" is specified once for each monitor. Thanks. :) -- Seth Arnold | http://www.willamette.edu/~sarnold/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DPMS
On 18 Sep 2000, Oystein Viggen bashed his keyboard into the wall and hit the following keys: > With the XFree 4.x-packages, this no longer works - the screen just goes > blank, but does not power down. Is this a known bug, and is there a > workaround? You need to activate DPMS explicitly in the XF86Config file to get DPMS. IIRC, you need a line called 'Option "DPMS"' in the Monitor section. -- Simon Kongshoj - email: [EMAIL PROTECTED] - http://www.cs.auc.dk/~simon Why have your OS perform illegal actions when you can do it yourself?
DPMS
Hi In XFree 3.3.6 and earlier versions, I used to be able to make the computer screen turn it self off (soft off) after 20 minutes by using "xset dpms 1200 1200 1200". With the XFree 4.x-packages, this no longer works - the screen just goes blank, but does not power down. Is this a known bug, and is there a workaround? Oystein
Re: XFree86, Mesa, Debian, and libGLU revisited
Branden Robinson wrote: > > However, a consensus has formed of late among the XFree86 developers, in > conjunction with Brian Paul (the mastermind of the Mesa project), that > libGLU should be shipped, built and installed with the rest of Mesa as part > of the XFree86 distribution. I've corresponded with Brian on this point, > and he suggests that the 3 libraries, libGL, libGLU, and libOSMesa, be > shipped in one package. I see no compelling reason to do otherwise. > What is Debian's policy regarding OpenGL libraries provided by the hardware vendor (NVidia, for example)? Don't we get a packaging conflict here? Regards Harri -- Harald Dunkel | [EMAIL PROTECTED] | If your operating system seems to Synopsys GmbH | Kaiserstr. 100 | be made by Dr. Frankenstein, then 52134 Herzogenrath, Germany| it is time for a change. +49 2407 9558 (fax? 44: 0) |Try Linux!
Re: XFree86, Mesa, Debian, and libGLU revisited
Hi, sorry for getting in the middle of the conversation... >> Branden Robinson <[EMAIL PROTECTED]> writes: > The XFree86 source tree, which contains Mesa (libGL and libOSMesa, > the off-screen rendering library), does *not* contain libGLU. I > don't honestly know why this choice was originally made (I get the > impression it has something do with libGLU being written in C++ -- > no other part of the XFree86 source distribution is). Brian stated some months ago (and again last week) he wants to retire the libGLU code from Mesa and use the SGI's Sample Implementation code instead. What you say seems to indicate he changed his mind. One issue with this idea is that the SI is under the SGI Free License B[1] which was discussed on debian-legal sometime ago. Our concern (James' and mine) focused on a clause that states you can't implement the SI in hardware (or something like that, I don't remember the exact wording off the top of my head). -legal raised some questions regarding other clauses in the license (most people seemed to be cool with the one I mention), but nothing clear ever came out. Anyway, you might be interested in exerting some pressure in order to resolve this issue, because GLX on the XFree86 source tree is under this same license (I recall sending you a mail about this more than a month ago, but xserver-xfree86/copyright doesn't list this license) On the positive side, if James Treacy (our mesa maintainer) isn't interested in doing so, eventually I'd like to package the whole SI for Debian. I already have done a bit of work on this, but building it has proven to be tricky, plus I've been tied up with other things lately... > + The off-screen rendering library, libOSMesa, is not yet available in the > Debian Mesa packages (last I checked); this should be remedied when an > official upstream version of Mesa is released with it (which I don't > think has happened yet) and when the Debian package maintainer then > releases it OSMesa has been a part of Mesa for quite a long time. Cheers, Marcelo [1] http://oss.sgi.com/projects/FreeB
Re: DPMS
On 18 Sep 2000, Oystein Viggen bashed his keyboard into the wall and hit the following keys: > With the XFree 4.x-packages, this no longer works - the screen just goes > blank, but does not power down. Is this a known bug, and is there a > workaround? You need to activate DPMS explicitly in the XF86Config file to get DPMS. IIRC, you need a line called 'Option "DPMS"' in the Monitor section. -- Simon Kongshoj - email: [EMAIL PROTECTED] - http://www.cs.auc.dk/~simon Why have your OS perform illegal actions when you can do it yourself? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
DPMS
Hi In XFree 3.3.6 and earlier versions, I used to be able to make the computer screen turn it self off (soft off) after 20 minutes by using "xset dpms 1200 1200 1200". With the XFree 4.x-packages, this no longer works - the screen just goes blank, but does not power down. Is this a known bug, and is there a workaround? Oystein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86, Mesa, Debian, and libGLU revisited
Branden Robinson wrote: > > However, a consensus has formed of late among the XFree86 developers, in > conjunction with Brian Paul (the mastermind of the Mesa project), that > libGLU should be shipped, built and installed with the rest of Mesa as part > of the XFree86 distribution. I've corresponded with Brian on this point, > and he suggests that the 3 libraries, libGL, libGLU, and libOSMesa, be > shipped in one package. I see no compelling reason to do otherwise. > What is Debian's policy regarding OpenGL libraries provided by the hardware vendor (NVidia, for example)? Don't we get a packaging conflict here? Regards Harri -- Harald Dunkel | [EMAIL PROTECTED] | If your operating system seems to Synopsys GmbH | Kaiserstr. 100 | be made by Dr. Frankenstein, then 52134 Herzogenrath, Germany| it is time for a change. +49 2407 9558 (fax? 44: 0) |Try Linux! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
