Xavier Chantry <chantry.xav...@gmail.com> writes: > 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 l > oad > 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 ?
That's just the default compiler/linker setup on Linux. This is in contrast to, say, OS X, where undefined symbols cause link errors. You can emulate the above by building with -Wl,--no-undefined (or maybe -no-undefined, something like that, see ld(1)). > 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 ? Doesn't effect me personally, but errors coming up on stderr does seem like reasonable default behavior to me. Is it actually the case that these are always errors though (i.e. if a dlopen fails, does a higher level try loading a different driver which might succeed?)? -tom ------------------------------------------------------------------------------ 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
