Maurice van der Pot wrote:
On Mon, May 24, 2004 at 08:54:27AM -0700, Ian Romanick wrote:
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.
Then just 'cp -a /usr/X11R6 /usr/X11R6.bak'. If you want to revert to your original X setup, 'mv /usr/X11R6 /usr/X11R6.dri ; mv /usr/X11R6.bak /usr/X11R6'. It's important to do the cp the first time because the DRI needs some stuff from an X install. We don't include everything in the source tree.
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)
That's not right. You should be using a build tree, first off. Secondly, you should point at the exports directory. If you're doing everything in the DRI tree, your LIBGL_DRIVERS_DIR would be .../build/xc/exports/lib/modules/dri.
If you think that doing a make install once will change things, then I'll do it.
It's worth a try anyway. Although, it sounds like you're getting all the right files anyway. How big is your r200_dri.so? It should be on the order of 17MB (yes, seventeen) if it has debug information.
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.
Okay. There's 3 parts of a 3D driver (excluding the parts that live in the 2D driver). There's the kernel module. That's the DRM stuff, and it lives in the drm module of the DRI project. There's the driver loader. That is part of what libGL does. libGL communicates with the X server (which communicates, via the 2D driver, with the kernel part) to determine which 3D driver to load and to setup some aspects of the hardware. Almost all of the code for libGL lives in xc/xc/lib/GL/glx in the DRI tree. Some of the code for it comes from the Mesa tree.
The 3rd part, and the part that is most intersting to most people, is the 3D driver itself. All of the code, except a small library used to communicate with the kernel, lives in the Mesa tree. If you edit the DRM_SOURCE_PATH in configs/default to point to the drm sources (the drm module from the DRI tree mentioned above), you can do 'make linux-dri' in your Mesa tree to build the *_dri.so files. They will end up in the lib directory at the top of the Mesa tree. There are also linux-dri-x86 and linux-dri-x86-64 targets. The advantage is that you're doing all your work in one tree AND the build ends up being faster.
In the (hopefully near) future, the DRI tree will contain a stable copy of the Mesa tree. At that time, all driver work (and builds) will happen in the Mesa tree. You really only need to do builds in the DRI tree if you're working on libGL, working on the server-side GLX stuff, or working on the 2D driver.
Truth be told, you could just grab a newer libGL.so from one of the nightly snapshots and never get the xc tree at all.
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.
That's really, really weird. Can you give some more details about your system? What distro are you using? glibc version? gdb version? This stuff has worked for me out of the box on every Redhat version from 7.1 through FC1. You might need to ask about this on one of the gdb user lists.
-------------------------------------------------------
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
