On Mon, 2010-03-15 at 00:09 +0100, Xavier Chantry wrote: > 14:47 < lb1> the fact is that if you remove a function from mesa .c file, > everything will succeed, but the resulting driver will fail to > load > 14:47 < lb1> because it cannot resolve that symbol > 14:48 < lb1> not sure why > 14:48 < lb1> I suppose even for shared libraries gcc/ld should fail on > undefined symbols > 14:48 < lb1> maybe the makefiles disable that checking > > Can anyone shed any light on this, why the driver always succeeds to > build and link even in the case of undefined symbols ?
One complication is that the driver needs symbols from libGL and vice versa. Probably nothing that can't be solved with sufficient toolchain-fu though. > The second question is why the dlopen errors are not visible by > default and require LIBGL_DEBUG=verbose to be displayed. > It does not make sense to always print these errors by default ? One problem is that drivers can be loaded from several paths; if the HW driver fails to load from the first path but succeeds from the next one, any error messages from the first attempt would be confusing. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
