dri: test whether the built drivers have unresolved symbols
authorLuca Barbieri <luca@luca-barbieri.com>
Mon, 15 Mar 2010 17:36:27 +0000 (18:36 +0100)
committerLuca Barbieri <luca@luca-barbieri.com>
Tue, 23 Mar 2010 14:28:59 +0000 (15:28 +0100)
commit3e17a5b047124c46ee45dbd1848127c67e0d62f3
treede5dc1f5dd71dd6838b431495433269b8f9a2b6d
parent1f25eca311715f5ebceaee50ba4d68c3c9ea79a6
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 <chantry.xavier@gmail.com> and
Michel Daenzer <michel@daenzer.net> for helping with this.

Signed-off-by: Luca Barbieri <luca@luca-barbieri.com>
Acked-by: Brian Paul <brian.e.paul@gmail.com>
src/gallium/winsys/drm/Makefile.template
src/mesa/drivers/dri/Makefile.template
src/mesa/drivers/dri/common/dri_test.c [new file with mode: 0644]