[Mesa-dev] [PATCHES] clang compatibility

Keith Whitwell keithw at vmware.com
Tue Aug 24 04:25:48 PDT 2010


On Mon, 2010-08-23 at 14:09 -0700, José Fonseca wrote:
> On Sun, 2010-08-22 at 02:35 -0700, nobled wrote:
> > The first three attached patches make it possible to compile Mesa with
> > LLVM/Clang:
> > 1. Add -lstdc++ when linking glsl_compiler and glcpp
> > 2. Move -lstdc++ from the Gallium-specific Makefile.dri to
> > DRI_LIB_DEPS in configure (fixes linking classic Mesa drivers)
> > 3. Since autoconf gives GCC=yes even when using clang (since it just
> > tests for the __GNUC__ macro), don't check for a minimum version of
> > 3.3 if $(CC) points to a clang executable. (unfortunately I'm not sure
> > how to properly detect clang, short of test-compiling a file that
> > contains #ifdef __clang__. I.e. if $(CC) = 'cc', and 'cc' is an
> > alternatives symlink to llvm-clang, this doesn't detect that case.)
> > 
> > The rest are just fixes to compiler warnings:
> > 4. dri: Fix implicit declaration
> > 5. program: Fix struct/class confusion
> > 6. dr/radeon: Fix printf format
> > 7. llvmpipe: Fix memory leak
> > 
> > With the first three patches, I can compile Mesa with clang 2.7 in
> > Ubuntu Lucid if I export three variables before configure:
> > export CC=llvm-clang
> > export CXX=llvm-clang
> > export CPPFLAGS=/usr/lib/clang/1.1/include
> > ./configure
> > (Yeah, the third one is really prone to breakage with new versions and
> > I'm still trying to figure out how to not need it; it should also get
> > passed as part of MKDEP_OPTIONS in configure.ac, TBH.)
> 
> The llvmpipe patch looks correct to me, as draw_destroy doesn't destroy
> vbuf.
> 
> But if so then interface looks bad to me -- what's the point of putting
> a destroy callback in the interface if it's never used by the other side
> of the interface? Perhaps Keith can make a call of what's the right
> thing to do here.

Yes, that could be cleaned up if anyone has the time to do so.
Basically there's a question mark about who owns the vbuf entity - the
driver or draw module?  It was the driver initially, but now it really
looks like it should be the draw module.

Keith



More information about the mesa-dev mailing list