Thanks for your response Ian.
On Mon, May 24, 2004 at 08:54:27AM -0700, Ian Romanick wrote:
>
> How are you building? Are you building everything in the DRI tree?
> libGL in the DRI tree and the drivers in the Mesa tree? The libGL built
> in the Mesa tree is *NOT* the one used with the DRI drivers. The libGL
> built in the DRI tree (or from the DRI binary snapshots) should have all
> the debug symbols included.
I was building everything from the DRI tree. I noticed that I had to use
the libGL in the DRI tree because of the timestamp.
> As for r200_dri.so, are you sure it's getting the right one? If you run
> with 'LIBGL_DEBUG=verbose' it will print out which driver binary is
> being used.
The modifications I made to the driver were visible when I executed an
OpenGL app, so I knew it was using the right r200_dri.so. Strangely,
I was unable to get most of the debug prints working. The general ones
with LIBGL_DEBUG seemed to work, but not the r200 specific ones.
> For a developer, the best bet is to get the DRI tree and the Mesa tree.
> Build the DRI tree and do a 'make install' as root *once*.
The thing is that I didn't want to modify (pollute? ruin?) my working X
install and was trying to make things work completely as a normal user.
For this I set LIBGL_DRIVERS_DIR to
/home/griffon26/cvs-wa/xc/xc/lib/GL/mesa/drivers/dri/r200
and I added /home/griffon26/cvs-wa/xc/xc/lib/GL/GL/ to my LD_LIBRARY_PATH.
ldd then told me that my OpenGL app was using the right libGL:
libGL.so.1 => /home/griffon26/cvs-wa/xc/xc/lib/GL/GL/libGL.so.1 (0x40014000)
If you think that doing a make install once will change things, then
I'll do it.
> Then do
> your development in the Mesa tree, build your drivers in the Mesa tree,
> and run with 'LIBGL_DRIVERS_DIR' set to the lib directory in the Mesa
> tree (i.e., from the top of the Mesa tree do 'export
> LIBGL_DRIVERS_DIR=$(pwd)/lib'.
But you just said that the libGL in the Mesa tree was not the one to be
used? I'm confused why I should do development in the Mesa tree, because
the DRI tree has links to the source files in the Mesa tree, so I can
modify and build there. All I would ever have to do in the mesa tree is
run cvs commands, right? I don't even think I _can_ do a build from the
Mesa tree.
I still don't understand why GDB is acting strange. Maybe this is something
I have to figure out on my own, because I don't think it's DRI specific.
Anyway, here's what happens when I type sharedlibrary after I hit a breakpoint
on a glBegin call.
(gdb) sharedlibrary
Symbols already loaded for /home/griffon26/cvs-wa/xc/xc/lib/GL/GL/libGL.so.1
Symbols already loaded for /usr/lib/libGLU.so.1
Symbols already loaded for /usr/lib/libglut.so.3
[etc etc]
Symbols already loaded for /usr/X11R6/lib/libXt.so.6
Reading symbols from
/home/griffon26/cvs-wa/xc/xc/lib/GL/mesa/drivers/dri/r200/r200_dri.so...done.
Loaded symbols for
/home/griffon26/cvs-wa/xc/xc/lib/GL/mesa/drivers/dri/r200/r200_dri.so
(gdb)
auto-solib-add was already on.
I do get this message when I run my program in gdb... maybe that's why
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Best regards,
Maurice.
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
