Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kristian Høgsberg wrote: > Ok, big disclaimer here: I haven't looked into glucose or even glitz > much, so what I'm suggesting here may not apply. But my take is that > we shouldn't be loading libGL in the X server to begin with. If we > want to use opengl in the X server we should call into the dispatch > table directly (as for example the __glXDRIbindTexImage implementation > in GL/glx/glxdri.c: > > CALL_GetIntegerv(GET_DISPATCH(), (glxPixmap->target == GL_TEXTURE_2D ? > GL_TEXTURE_BINDING_2D : > GL_TEXTURE_BINDING_RECTANGLE_NV, > &texname)); I think that's correct. Alternately (preferably?) we could generate a fake libGL or gl_calls.h or something so that we can do glGetIntegerv(...) and have it be expanded directly to the above for us. We shouldn't link libGL with the X server any more than we'd link Xlib with it. > and we may have to export some of the GLX code for use inside the X > server (creating glx drawables and contexts etc) and separate out the > protocol stuff. Basically if we have to hack around linking issues > and fudge symbol resolution issues we're doing something wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG+v30X1gOwKyEAw8RAqSkAJ9weVM3XSBzC5bL84xVwJ9D5KtkXgCdEfgm BRH8+WHsAB1oRAwbW7JgTC0= =59EP -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)
On Wed, 2007-09-26 at 14:15 -0400, Kristian Høgsberg wrote: > On 9/20/07, José Fonseca <[EMAIL PROTECTED]> wrote: > > On 9/19/07, Gabor Gombas <[EMAIL PROTECTED]> wrote: > > > On Wed, Sep 19, 2007 at 10:20:49AM +, José Fonseca wrote: > > > > However, when loaded, references to __glXFreeContext *inside* > > > > libglxgext.so are linked to the external __glXFreeContext in libGL.so: > > > > > > If you have multiple definitions for a symbol it is completely random > > > which a given reference will resolve to. > > > > > > Now, the two underscores are a good hint that these are internal symbols > > > and they should not be exported at all or if they have to, one of them > > > must be renamed. > > > > > > > libtool's -export-dynamic flag is not being used. Using libtool's > > > > -module > > > > flag doesn't change anything. > > > > > > Does this symbol have to be exported? If no, you should use libtool's > > > --export-symbol feature to explicitely declare which symbols should be > > > visible and which should not. In fact, it is always wise to use > > > --export-symbol when creating shared libraries to prevent ABI breakage > > > by accidentally exporting private symbols. > > > > > > If __glXFreeContext should be exported, then it should be decided which > > > library owns this symbol, and the other must be modified not to export > > > it. > > > > > > If it is the case that libGL.so exports __glXFreeContext but > > > libglxgext.so wants to locally override it, and for some reason you > > > absolutely cannot rename it, then you must use gcc's > > > __visibility__((__protected__)) attribute when declaring __glXFreeContext > > > in libglgxext.so, but that is not portable to non-ELF platforms and > > > other compilers and also has run-time performance costs IIRC. > > > > I agree in principle with your suggestions. But I'm not entitled to > > decide if __glX* symbols > > should or not be exported, nor to say what's the best way to accomplish it. > > > > I know that __glX* functions came originally from SGI code. From there > > derived copies appear on mesa (for libGL), and more than once in > > xserver code -- I suppose always for indirect rendering purposes (in > > places such as AIGLX, DMX, and Xgl). It is likely that other vendors > > also ship libGL exporting those symbols. > > > > But it would definitely make things simpler and less likely to break > > if the __glX* symbols were not exported... > > Ok, big disclaimer here: I haven't looked into glucose or even glitz > much, so what I'm suggesting here may not apply. But my take is that > we shouldn't be loading libGL in the X server to begin with. If we > want to use opengl in the X server we should call into the dispatch > table directly (as for example the __glXDRIbindTexImage implementation > in GL/glx/glxdri.c: > > CALL_GetIntegerv(GET_DISPATCH(), (glxPixmap->target == GL_TEXTURE_2D ? > GL_TEXTURE_BINDING_2D : > GL_TEXTURE_BINDING_RECTANGLE_NV, > &texname)); > > and we may have to export some of the GLX code for use inside the X > server (creating glx drawables and contexts etc) and separate out the > protocol stuff. Basically if we have to hack around linking issues > and fudge symbol resolution issues we're doing something wrong. glucose is already doing what you say above Kristian, it's definitely not loading libGL. Remember Xgl is an OpenGL client, and that's where the problems are caused. Nothing to do with glucose here. Alan. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)
On 9/26/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > On 9/20/07, José Fonseca <[EMAIL PROTECTED]> wrote: > > On 9/19/07, Gabor Gombas <[EMAIL PROTECTED]> wrote: > > > On Wed, Sep 19, 2007 at 10:20:49AM +, José Fonseca wrote: > > > > However, when loaded, references to __glXFreeContext *inside* > > > > libglxgext.so are linked to the external __glXFreeContext in libGL.so: > > > > > > If you have multiple definitions for a symbol it is completely random > > > which a given reference will resolve to. > > > > > > Now, the two underscores are a good hint that these are internal symbols > > > and they should not be exported at all or if they have to, one of them > > > must be renamed. > > > > > > > libtool's -export-dynamic flag is not being used. Using libtool's > > > > -module > > > > flag doesn't change anything. > > > > > > Does this symbol have to be exported? If no, you should use libtool's > > > --export-symbol feature to explicitely declare which symbols should be > > > visible and which should not. In fact, it is always wise to use > > > --export-symbol when creating shared libraries to prevent ABI breakage > > > by accidentally exporting private symbols. > > > > > > If __glXFreeContext should be exported, then it should be decided which > > > library owns this symbol, and the other must be modified not to export > > > it. > > > > > > If it is the case that libGL.so exports __glXFreeContext but > > > libglxgext.so wants to locally override it, and for some reason you > > > absolutely cannot rename it, then you must use gcc's > > > __visibility__((__protected__)) attribute when declaring __glXFreeContext > > > in libglgxext.so, but that is not portable to non-ELF platforms and > > > other compilers and also has run-time performance costs IIRC. > > > > I agree in principle with your suggestions. But I'm not entitled to > > decide if __glX* symbols > > should or not be exported, nor to say what's the best way to accomplish it. > > > > I know that __glX* functions came originally from SGI code. From there > > derived copies appear on mesa (for libGL), and more than once in > > xserver code -- I suppose always for indirect rendering purposes (in > > places such as AIGLX, DMX, and Xgl). It is likely that other vendors > > also ship libGL exporting those symbols. > > > > But it would definitely make things simpler and less likely to break > > if the __glX* symbols were not exported... > > Ok, big disclaimer here: I haven't looked into glucose or even glitz > much, so what I'm suggesting here may not apply. But my take is that > we shouldn't be loading libGL in the X server to begin with. If we > want to use opengl in the X server we should call into the dispatch > table directly (as for example the __glXDRIbindTexImage implementation > in GL/glx/glxdri.c: > > CALL_GetIntegerv(GET_DISPATCH(), (glxPixmap->target == GL_TEXTURE_2D ? > GL_TEXTURE_BINDING_2D : > GL_TEXTURE_BINDING_RECTANGLE_NV, > &texname)); > > and we may have to export some of the GLX code for use inside the X > server (creating glx drawables and contexts etc) and separate out the > protocol stuff. Basically if we have to hack around linking issues > and fudge symbol resolution issues we're doing something wrong. The thread's subject is a bit misleading, but this problem actually only happens on Xgl (which is supposed to link to the system /usr/lib/libGL which may even have nothing to do with the DRI, but it get's duplicates when it does). glucose reuses some of the Xgl code, but it bypasses libGL, and uses AIGLX as you are suggesting. José Fonseca - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)
On 9/20/07, José Fonseca <[EMAIL PROTECTED]> wrote: > On 9/19/07, Gabor Gombas <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 19, 2007 at 10:20:49AM +, José Fonseca wrote: > > > However, when loaded, references to __glXFreeContext *inside* > > > libglxgext.so are linked to the external __glXFreeContext in libGL.so: > > > > If you have multiple definitions for a symbol it is completely random > > which a given reference will resolve to. > > > > Now, the two underscores are a good hint that these are internal symbols > > and they should not be exported at all or if they have to, one of them > > must be renamed. > > > > > libtool's -export-dynamic flag is not being used. Using libtool's -module > > > flag doesn't change anything. > > > > Does this symbol have to be exported? If no, you should use libtool's > > --export-symbol feature to explicitely declare which symbols should be > > visible and which should not. In fact, it is always wise to use > > --export-symbol when creating shared libraries to prevent ABI breakage > > by accidentally exporting private symbols. > > > > If __glXFreeContext should be exported, then it should be decided which > > library owns this symbol, and the other must be modified not to export > > it. > > > > If it is the case that libGL.so exports __glXFreeContext but > > libglxgext.so wants to locally override it, and for some reason you > > absolutely cannot rename it, then you must use gcc's > > __visibility__((__protected__)) attribute when declaring __glXFreeContext > > in libglgxext.so, but that is not portable to non-ELF platforms and > > other compilers and also has run-time performance costs IIRC. > > I agree in principle with your suggestions. But I'm not entitled to > decide if __glX* symbols > should or not be exported, nor to say what's the best way to accomplish it. > > I know that __glX* functions came originally from SGI code. From there > derived copies appear on mesa (for libGL), and more than once in > xserver code -- I suppose always for indirect rendering purposes (in > places such as AIGLX, DMX, and Xgl). It is likely that other vendors > also ship libGL exporting those symbols. > > But it would definitely make things simpler and less likely to break > if the __glX* symbols were not exported... Ok, big disclaimer here: I haven't looked into glucose or even glitz much, so what I'm suggesting here may not apply. But my take is that we shouldn't be loading libGL in the X server to begin with. If we want to use opengl in the X server we should call into the dispatch table directly (as for example the __glXDRIbindTexImage implementation in GL/glx/glxdri.c: CALL_GetIntegerv(GET_DISPATCH(), (glxPixmap->target == GL_TEXTURE_2D ? GL_TEXTURE_BINDING_2D : GL_TEXTURE_BINDING_RECTANGLE_NV, &texname)); and we may have to export some of the GLX code for use inside the X server (creating glx drawables and contexts etc) and separate out the protocol stuff. Basically if we have to hack around linking issues and fudge symbol resolution issues we're doing something wrong. cheers, Kristian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] libGL exported __glX* symbols (Was: glucose and xgl progress)
On Thu, 2007-09-20 at 13:50 +0100, José Fonseca wrote: > On 9/19/07, Gabor Gombas <[EMAIL PROTECTED]> wrote: > > On Wed, Sep 19, 2007 at 10:20:49AM +, José Fonseca wrote: > > > However, when loaded, references to __glXFreeContext *inside* > > > libglxgext.so are linked to the external __glXFreeContext in libGL.so: > > > > If you have multiple definitions for a symbol it is completely random > > which a given reference will resolve to. > > > > Now, the two underscores are a good hint that these are internal symbols > > and they should not be exported at all or if they have to, one of them > > must be renamed. > > > > > libtool's -export-dynamic flag is not being used. Using libtool's -module > > > flag doesn't change anything. > > > > Does this symbol have to be exported? If no, you should use libtool's > > --export-symbol feature to explicitely declare which symbols should be > > visible and which should not. In fact, it is always wise to use > > --export-symbol when creating shared libraries to prevent ABI breakage > > by accidentally exporting private symbols. > > > > If __glXFreeContext should be exported, then it should be decided which > > library owns this symbol, and the other must be modified not to export > > it. > > > > If it is the case that libGL.so exports __glXFreeContext but > > libglxgext.so wants to locally override it, and for some reason you > > absolutely cannot rename it, then you must use gcc's > > __visibility__((__protected__)) attribute when declaring __glXFreeContext > > in libglgxext.so, but that is not portable to non-ELF platforms and > > other compilers and also has run-time performance costs IIRC. > > I agree in principle with your suggestions. But I'm not entitled to > decide if __glX* symbols should or not be exported, [...] Neither am I :), but AFAICT they aren't currently referenced outside of their respective modules, and they probably shouldn't be. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
