On Mon, Mar 15, 2010 at 6:36 PM, Luca Barbieri <l...@luca-barbieri.com> wrote: > This is a different approach to solving this problem that the patch > I previously posted, and unlike that, should not cause any problems. > > Right now undefined symbols in DRI drivers will still allow the > build to succeed. > > As a result, people modifying drivers they cannot test risk creating > unloadable drivers with no easy way of automatically avoiding it. > > For instance, the modifications to nv50 for context transfers caused > such an issue recently. > > Unfortunately, just adding -Wl,--no-undefined doesn't work, because > the DRI drivers depend on glapi symbols, but do not depend on > libGL.so.1 > > Adding -lGL is not the correct solution since DRI drivers are not loaded > just by libGL, but also by X and possibly by other clients. > > So, this patch simply tries to build an executable linked to the DRI > driver and to libGL. > If the DRI driver contains any undefined symbols not satisfied by its > dependencies or by libGL, this will fail. > > This solution does not alter the built drivers, and does not significantly > slow down the build process. > > All classic DRI drivers as well as all the Gallium drivers with configure > options compiled successfully with this change. > > Thanks to Xavier Chantry <chantry.xav...@gmail.com> and > Michel Daenzer <mic...@daenzer.net> for helping with this. > ---
Just tested, that also works for me. ------------------------------------------------------------------------------ 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