[Dri-devel] Problem with t_vtx_x86_gcc.S in DRI build system
Hi, in the DRI build system t_vtx_x86_gcc.S ends up being compiled this command: gcc -c -o t_vtx_x86_gcc.o t_vtx_x86_gcc.S The defined like -DUSE_X86_ASM are not there because they are defined as CFLAGS which are not used for compiling assembler sources files. Because of the conditional statement at the top of t_vtx_x86_gcc.S several symbols are undefined in the resulting 3D drivers: #if defined(USE_X86_ASM) !defined(HAVE_NONSTANDARD_GLAPIENTRY) Is this conditional really needed? If yes then the Imakefiles in DRI have to be fixed to set all the defines in CPPFLAGS, not in CFLAGS. Though I don't know if this works with all make versions that XFree86 supports. The attached patch is a quick and dirty workaround. However, this way the ASM_DEFS end up twice on the command lines of all .c-files in the tnl directory. Regards, Felix --- ./Imakefile.~1.3.~ 2004-04-01 12:02:01.0 +0200 +++ ./Imakefile 2004-04-01 14:39:23.0 +0200 @@ -86,6 +86,7 @@ SRCS = $(MESA_TNL_SRCS) OBJS = $(MESA_TNL_OBJS) + CPPFLAGS = $(ASM_DEFS) #include Library.tmpl
[Dri-devel] Conflicting symbols between radeon/r200_vtxtmp_x86.o and t_vtx_x86_gcc.o
Hi, when linking the radeon and r200 drivers I get these errors: radeon_vtxtmp_x86.o(.data+0x18c): In function `_x86_Vertex3fv': : multiple definition of `_x86_Vertex3fv' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x80): first defined here radeon_vtxtmp_x86.o(.data+0x1d3): In function `_x86_Attribute2f': : multiple definition of `_x86_Vertex3fv_end' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0xc7): first defined here radeon_vtxtmp_x86.o(.data+0x1e6): In function `_x86_Attribute2fv': : multiple definition of `_x86_Attribute2fv' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x121): first defined here radeon_vtxtmp_x86.o(.data+0x1fb): In function `_x86_Attribute3f': : multiple definition of `_x86_Attribute2fv_end' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x136): first defined here radeon_vtxtmp_x86.o(.data+0x219): In function `_x86_Attribute3fv': : multiple definition of `_x86_Attribute3fv' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x136): first defined here radeon_vtxtmp_x86.o(.data+0x237): In function `_x86_Color4ubv_ub': : multiple definition of `_x86_Attribute3fv_end' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x154): first defined here I have no idea how to fix this because I don't know how the tnl_vtxfmt code is supposed to interact with the vtxfmt code in the radeon drivers. Can someone please fix this or disable the tnl vtxfmt code until this has been sorted out? Regards, Felix --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Conflicting symbols between radeon/r200_vtxtmp_x86.o and t_vtx_x86_gcc.o
Felix Kühling wrote: Hi, when linking the radeon and r200 drivers I get these errors: radeon_vtxtmp_x86.o(.data+0x18c): In function `_x86_Vertex3fv': : multiple definition of `_x86_Vertex3fv' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x80): first defined here radeon_vtxtmp_x86.o(.data+0x1d3): In function `_x86_Attribute2f': : multiple definition of `_x86_Vertex3fv_end' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0xc7): first defined here radeon_vtxtmp_x86.o(.data+0x1e6): In function `_x86_Attribute2fv': : multiple definition of `_x86_Attribute2fv' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x121): first defined here radeon_vtxtmp_x86.o(.data+0x1fb): In function `_x86_Attribute3f': : multiple definition of `_x86_Attribute2fv_end' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x136): first defined here radeon_vtxtmp_x86.o(.data+0x219): In function `_x86_Attribute3fv': : multiple definition of `_x86_Attribute3fv' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x136): first defined here radeon_vtxtmp_x86.o(.data+0x237): In function `_x86_Color4ubv_ub': : multiple definition of `_x86_Attribute3fv_end' ../../../../../../lib/GL/mesa/tnl/t_vtx_x86_gcc.o(.data+0x154): first defined here I have no idea how to fix this because I don't know how the tnl_vtxfmt code is supposed to interact with the vtxfmt code in the radeon drivers. Can someone please fix this or disable the tnl vtxfmt code until this has been sorted out? I'll rename those symbols to avoid the conflict. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Problem with t_vtx_x86_gcc.S in DRI build system
Felix Kühling wrote: Hi, in the DRI build system t_vtx_x86_gcc.S ends up being compiled this command: gcc -c -o t_vtx_x86_gcc.o t_vtx_x86_gcc.S The defined like -DUSE_X86_ASM are not there because they are defined as CFLAGS which are not used for compiling assembler sources files. Because of the conditional statement at the top of t_vtx_x86_gcc.S several symbols are undefined in the resulting 3D drivers: #if defined(USE_X86_ASM) !defined(HAVE_NONSTANDARD_GLAPIENTRY) Is this conditional really needed? I guess it's not needed for compilation, but this code definitely won't work on those systems with a non-standard calling convention. So, the test could be moved elsewhere if that helps. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Problem with t_vtx_x86_gcc.S in DRI build system
On Thu, 01 Apr 2004 16:28:43 +0100 Keith Whitwell [EMAIL PROTECTED] wrote: Felix Kühling wrote: Hi, in the DRI build system t_vtx_x86_gcc.S ends up being compiled this command: gcc -c -o t_vtx_x86_gcc.o t_vtx_x86_gcc.S The defined like -DUSE_X86_ASM are not there because they are defined as CFLAGS which are not used for compiling assembler sources files. Because of the conditional statement at the top of t_vtx_x86_gcc.S several symbols are undefined in the resulting 3D drivers: #if defined(USE_X86_ASM) !defined(HAVE_NONSTANDARD_GLAPIENTRY) Is this conditional really needed? I guess it's not needed for compilation, but this code definitely won't work on those systems with a non-standard calling convention. So, the test could be moved elsewhere if that helps. The same test is already in t_vtx_x86.c. So the assembler functions won't be used if the condition is false, even if they are compiled and linked into the driver. Keith Felix --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] bug - execute permissions on data areas
Hmm... I can't seem to find a working bugzilla for DRI, instead things seem to be directed here. I just opened the following bug for xorg, it fixes various pieces of code that need to set execute permission on data memory. Some of these are in DRI and Mesa, it would be great if could get these fixes upstream. Full explanation in the bugzilla referenced. http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=399 -- John Dennis [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] bug - execute permissions on data areas
John Dennis wrote: Hmm... I can't seem to find a working bugzilla for DRI, instead things seem to be directed here. I just opened the following bug for xorg, it fixes various pieces of code that need to set execute permission on data memory. Some of these are in DRI and Mesa, it would be great if could get these fixes upstream. Full explanation in the bugzilla referenced. http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=399 Quite topical as we're currently adding more code which does this. I'll integrate your patch as part of this work. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] (03-04-2004) - present Problem with libdri.a in snapshots
Craig Sowadski wrote: I am getting the following error when trying to run any DRI/GL program using snapshots staring at with radeon-20040304-linux.i386.tar.bz2 until present: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 144 (XFree86-DRI) Minor opcode of failed request: 5 () Value in failed request: 0x49 Serial number of failed request: 24 Current serial number in output stream: 24 I have traced the problem to be the file libdri.a, and must be something to do with this patch: http://dri.freedesktop.org/cgi-bin/cvsweb/dri/xc/xc/programs/Xserver/GL/dri/dri.c.diff?r1=1.50r2=1.51 Everything seems to work fine using the libdri.a from 03-03-2004 with the newest snapshot drivers. Let me know if you would like any other information. There we go! That's why I haven't been able to reproduce the problem! Can either libglx.a and libGLcore.a please be added to the binary snapshots or libdri.a be removed? I'm sure there is a reason, buy why are libdri.a and libdrm.a included at all? --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] More problems with t_vtx_x86_gcc.S
Ian Romanick wrote: If the code in t_vtx_x86.c is not built, then t_vtx_x86_gcc.S must not be built either. The code in the .S references symbols in the .c. That's why I put the #ifdef around all the code in the .S in version 1.3. I guess my cvs log message wasn't clear enough. :( I'm fixing this in my tree, but a better fix is needed. It's really hard to do any useful development in DRI or Mesa right now. :( Frankly, I'm happy to see this not being built in DRI at all at present, if you'd rather take a big-stick approach to this. Apologies to everyone once more for f*cking things up so completely. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] (03-04-2004) - present Problem with libdri.a in snapshots
Ian Romanick wrote: Craig Sowadski wrote: I am getting the following error when trying to run any DRI/GL program using snapshots staring at with radeon-20040304-linux.i386.tar.bz2 until present: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 144 (XFree86-DRI) Minor opcode of failed request: 5 () Value in failed request: 0x49 Serial number of failed request: 24 Current serial number in output stream: 24 I have traced the problem to be the file libdri.a, and must be something to do with this patch: http://dri.freedesktop.org/cgi-bin/cvsweb/dri/xc/xc/programs/Xserver/GL/dri/dri.c.diff?r1=1.50r2=1.51 Everything seems to work fine using the libdri.a from 03-03-2004 with the newest snapshot drivers. Let me know if you would like any other information. There we go! That's why I haven't been able to reproduce the problem! Can either libglx.a and libGLcore.a please be added to the binary snapshots or libdri.a be removed? I'm sure there is a reason, buy why are libdri.a and libdrm.a included at all? I think earlier libdrm.a didn't export the generic ioctl wrapper (drmCommand), but had a dinky wrapper for each ioctl. libdri.a, I can't remember, but there is a reason. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] tdfx snapshots
Hello, I got following problem with tdfx snapshots: [EMAIL PROTECTED] fritz]$ LIBGL_DEBUG=1 glxgears libGL error: dlopen /usr/X11R6/lib/modules/dri/tdfx_dri.so failed (/usr/X11R6/lib/modules/dri/tdfx_dri.so: undefined symbol: _mesa_init_driver_functions) libGL error: unable to find driver: tdfx_dri.so TIA for any help, regards, -- Fryderyk Dziarmagowski --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tdfx snapshots
On Thursday 01 April 2004 19:24, Fryderyk Dziarmagowski wrote: Hello, I got following problem with tdfx snapshots: [EMAIL PROTECTED] fritz]$ LIBGL_DEBUG=1 glxgears libGL error: dlopen /usr/X11R6/lib/modules/dri/tdfx_dri.so failed (/usr/X11R6/lib/modules/dri/tdfx_dri.so: undefined symbol: _mesa_init_driver_functions) libGL error: unable to find driver: tdfx_dri.so TIA for any help, regards, tdfx is broken at the moment. If you apply the patches I posted here: http://marc.theaimsgroup.com/?l=dri-develm=107940633518998w=2 then it will be marginally less broken; basic polygons will work but textures will not. I believe the texture breakage was a result of the DRI transition from Mesa 5.0.2 to 5.1 [1]; therefore in order to get a working tdfx driver right now, you'd need to find a snapshot from before December 9 2003, or alternatively compile a DRI CVS checkout from that date (following the old build instructions, which are basically just 'cvs co make World make install'). I'm not entirely clear on _how_ 5.1 broke texturing; I expect that my battle plan will be to step through the changes one commit at a time, which doesn't sound very fun. Clues, speculation, and conspiracy theories would be welcomed. - ajax [1] - Eric posted some test results after the newmesa merge that indicate that tdfx broke in the process: http://marc.theaimsgroup.com/?l=dri-develm=107104443215443w=2 . The testing I've done agrees with this; DRI with 5.0.2 works, DRI with 5.1 does not. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
