Re: libGLU and g++-3.2 (nurbs?)
On Mon, Oct 28, 2002 at 12:42:12PM -0500, Branden Robinson wrote: > > I assume all GL libraries in Debian will have this problem? > At least all GL libraries using C++ code, yes. > > Why would I call it xlibmesa3"c"? What does the "c" mean? > The "c" is the official addendum a C++ library should have, just like the "g" when libc transistion took place. > I'm not going to address this issue until I see Ryan Murray's document, > but thanks for bringing it to my attention. > As far as I am concerned, neuro wanted to publish it already. I'm actually trying to find out what happened, but i guess it will meet our MLs in nearer future (read as 'in next hours') > -- > G. Branden Robinson| Never underestimate the power of > Debian GNU/Linux | human stupidity. > [EMAIL PROTECTED] | -- Robert Heinlein > http://people.debian.org/~branden/ | -- .''`. Name: Martin Loschwitz : :' : E-Mail: [EMAIL PROTECTED] `. `'` www: http://www.madkiss.org/ `- Use Debian GNU/Linux - http://www.debian.org pgpdvO1CuCrTp.pgp Description: PGP signature
Re: libGLU and g++-3.2 (nurbs?)
On Mon, Oct 28, 2002 at 03:23:55PM +0100, Martin Loschwitz wrote: > At weekend, i created the first Qt3.1 .deb's and ran into a problem which is > bundled with the xfree86 "xlibmesa3" package. This is why i'm writing here. ;) > > Let me describe the problem: Qt3 supports linking against OpenGL library and > provides some functions which make it possible to use OpenGL with Qt3. If you > enable OpenGL in Qt3, libqt-mt.so.3.1.0 will link against libGL.so.1 -- and of > course, since Qt is pure C++, also against libstdc++5 (if it was compiled with > g++-3.2). > > libGL.so.1 is linked against libGLU.so.1 -- and there we have the problem: > libGLU contains g++-code, as far as i am concerned in NURBS, and is therefore > linked against libstdc++-libc6.2-2.so.3. Now you can see the dilemma: Qt3 is > linked against libstdc++5 directly and against libstdc++-libc6.2-2.so.3 via > libGLU -- this will most probably lead to trouble and un-usable Qt-OpenGL > apps > due to conflicting symbols. I assume all GL libraries in Debian will have this problem? > So i politely ask - does anybody have a solution for this issue? Maybe > disabling NURBS in the Mesa-library would do the job? Or can anybody > provide help with creating g++-3.2 packages of xlibmesa3 (xlibmesa3c, > that is)? I will, of course, help as good as i can with finding a solution. Why would I call it xlibmesa3"c"? What does the "c" mean? I'm not going to address this issue until I see Ryan Murray's document, but thanks for bringing it to my attention. -- G. Branden Robinson| Never underestimate the power of Debian GNU/Linux | human stupidity. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | pgph9VQA7jhqh.pgp Description: PGP signature
Re: libGLU and g++-3.2 (nurbs?)
On Mon, Oct 28, 2002 at 12:42:12PM -0500, Branden Robinson wrote: > > I assume all GL libraries in Debian will have this problem? > At least all GL libraries using C++ code, yes. > > Why would I call it xlibmesa3"c"? What does the "c" mean? > The "c" is the official addendum a C++ library should have, just like the "g" when libc transistion took place. > I'm not going to address this issue until I see Ryan Murray's document, > but thanks for bringing it to my attention. > As far as I am concerned, neuro wanted to publish it already. I'm actually trying to find out what happened, but i guess it will meet our MLs in nearer future (read as 'in next hours') > -- > G. Branden Robinson| Never underestimate the power of > Debian GNU/Linux | human stupidity. > [EMAIL PROTECTED] | -- Robert Heinlein > http://people.debian.org/~branden/ | -- .''`. Name: Martin Loschwitz : :' : E-Mail: [EMAIL PROTECTED] `. `'` www: http://www.madkiss.org/ `- Use Debian GNU/Linux - http://www.debian.org msg04439/pgp0.pgp Description: PGP signature
Re: libGLU and g++-3.2 (nurbs?)
On Mon, Oct 28, 2002 at 03:23:55PM +0100, Martin Loschwitz wrote: > At weekend, i created the first Qt3.1 .deb's and ran into a problem which is > bundled with the xfree86 "xlibmesa3" package. This is why i'm writing here. ;) > > Let me describe the problem: Qt3 supports linking against OpenGL library and > provides some functions which make it possible to use OpenGL with Qt3. If you > enable OpenGL in Qt3, libqt-mt.so.3.1.0 will link against libGL.so.1 -- and of > course, since Qt is pure C++, also against libstdc++5 (if it was compiled with > g++-3.2). > > libGL.so.1 is linked against libGLU.so.1 -- and there we have the problem: > libGLU contains g++-code, as far as i am concerned in NURBS, and is therefore > linked against libstdc++-libc6.2-2.so.3. Now you can see the dilemma: Qt3 is > linked against libstdc++5 directly and against libstdc++-libc6.2-2.so.3 via > libGLU -- this will most probably lead to trouble and un-usable Qt-OpenGL apps > due to conflicting symbols. I assume all GL libraries in Debian will have this problem? > So i politely ask - does anybody have a solution for this issue? Maybe > disabling NURBS in the Mesa-library would do the job? Or can anybody > provide help with creating g++-3.2 packages of xlibmesa3 (xlibmesa3c, > that is)? I will, of course, help as good as i can with finding a solution. Why would I call it xlibmesa3"c"? What does the "c" mean? I'm not going to address this issue until I see Ryan Murray's document, but thanks for bringing it to my attention. -- G. Branden Robinson| Never underestimate the power of Debian GNU/Linux | human stupidity. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | msg04436/pgp0.pgp Description: PGP signature
Re: libglu
> the gl lib in the phase1 debs conflicts with libutahglx (indirectly) but > doesn't provide the libglu.so file (so none of the xscreensaver > screensavers work, b/c they require glut). Copying out the lib from > libutahglx allows them to work, and they seem slightly accelerated (using > recent matrox driver), but my g200 is slow, so I can't really tell if it's > accelerated (as all i have to compare it to is a geforce2 ddr I had at > work). I'm assuming libglu is just an indriection library and it relies > on the underlying libgl, so that it would be accelerated. Hey W4R3Z 80Y, This issue has already been covered on this list. The mesa Debian maintainer will be splitting out libGLU into its own package. After that there will be no problem. -- G. Branden Robinson |There's nothing an agnostic can't do Debian GNU/Linux|if he doesn't know whether he believes [EMAIL PROTECTED] |in it or not. http://www.debian.org/~branden/ |-- Graham Chapman pgp4HPm6uDeCT.pgp Description: PGP signature
Re: libglu
> the gl lib in the phase1 debs conflicts with libutahglx (indirectly) but > doesn't provide the libglu.so file (so none of the xscreensaver > screensavers work, b/c they require glut). Copying out the lib from > libutahglx allows them to work, and they seem slightly accelerated (using > recent matrox driver), but my g200 is slow, so I can't really tell if it's > accelerated (as all i have to compare it to is a geforce2 ddr I had at > work). I'm assuming libglu is just an indriection library and it relies > on the underlying libgl, so that it would be accelerated. Hey W4R3Z 80Y, This issue has already been covered on this list. The mesa Debian maintainer will be splitting out libGLU into its own package. After that there will be no problem. -- G. Branden Robinson |There's nothing an agnostic can't do Debian GNU/Linux|if he doesn't know whether he believes [EMAIL PROTECTED] |in it or not. http://www.debian.org/~branden/ |-- Graham Chapman PGP signature
