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&#174; 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

Reply via email to