summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/tdfx/tdfx_texman.c
diff options
context:
space:
mode:
authorLuca Barbieri <[email protected]>2010-03-15 18:36:27 +0100
committerLuca Barbieri <[email protected]>2010-03-23 15:28:59 +0100
commit3e17a5b047124c46ee45dbd1848127c67e0d62f3 (patch)
treede5dc1f5dd71dd6838b431495433269b8f9a2b6d /src/mesa/drivers/dri/tdfx/tdfx_texman.c
parent1f25eca311715f5ebceaee50ba4d68c3c9ea79a6 (diff)
dri: test whether the built drivers have unresolved symbols
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 <[email protected]> and Michel Daenzer <[email protected]> for helping with this. Signed-off-by: Luca Barbieri <[email protected]> Acked-by: Brian Paul <[email protected]>
Diffstat (limited to 'src/mesa/drivers/dri/tdfx/tdfx_texman.c')
0 files changed, 0 insertions, 0 deletions