[Mesa-users] RES: Error compiling 8.0.2 in Windows, and some support

[Brian Paul]

On 05/04/2012 02:28 AM, Viral Patel wrote:
> I recently went through the process of building a mangled version of
> Mesa to perform software rendering on X11, GDI and OSMesa and perhaps
> some of my experience may help others, most of this is derived from
> various posts on the mesa forum and anything else I have managed to
> understand.
>
> ----------------------------------------
> I built using the 7.11.2 tar ball from
> freedesktop.org/mesa/mesa/snapshots
> <http://freedesktop.org/mesa/mesa/snapshots> (I read somewhere there
> are differences between this and the official release, there did
> appear to be but I didn't spend any time looking at whether
> the differences were relevant).
>
> *Prerequisites:*
>
> CMake 2.6
>
>     To build LLVM
>
> LLVM 2.8
>
>     There is a note else where to use the mingw version, I had no luck
>     with these, and building LLVM with CMake was a trivial, I would
>     recommend using the NMake generator on windows as the VCproj
>     generator had a bug shown with LLVM and 64bit targets.
>     To Build:
>          cd "LLVM-2.8"
>          mkdir "build" directory
>          cd "build"
>          cmake -G{NMake or GMake} .. // Use CMake to generate either
>     GNU Make
>                                                        // files or
>     NMake files on windows.
>          gmake or nmake
>          gmake or nmake install
>
> Python 2.7
>
>     I used 64bit
>
> Scons
>
>     Use the tarball, extract and run "python setup.py install" - if
>     you use 32bit python there are windows installers.
>
> Flex and Bison
>
>     For Linux these are easy to figure out, for windows see MINGW
>
> MINGW (Windows only)
>
>     Download and extract somewhere
>     run MinGW\msys\1.0\msys.bat
>     in msys - mingw-get install msys-flex msys-bison
>
>
> *Building Windows*
>
> Start a "Visual Studio 2008 x64 Command Prompt": NOTE - Fix the
> following paths
> for you install and there are helper batch files in
> Mesa/7.11.2/src/setup_*.bat.
>
>      set
> PATH=%PATH%;*<ROOT>*\MinGW\bin;*<ROOT>*\MinGW\msys\1.0\bin;*<ROOT>*\Python27;*<ROOT>*\Python\Scripts
>      set LLVM=*<ROOT>*\LLVM\x86_64
>      set CXXFLAGS=/DUSE_MGL_NAMESPACE
>      set CFLAGS=/DUSE_MGL_NAMESPACE
>      cd MesaLib-x.x.x
>      scons MSVS_VERSION=9.0 machine=x86_64  build=release
> platform=windows \
>          verbose=yes dri=no -j4 mesagdi osmesa glu
>
> For 32-bit use the same procedure as above but change x86_64.
>
> *Building Linux (for completeness)*
> *
> *
> I used configure/make and this worked well enough for me, although I
> needed to make some changes for our needs i.e. mangling.
>
>      cd MesaLib-x.x.x
>      make distclean
>
>      PATH={LLVM_INSTALL}/bin:$PATH \
>      CXXFLAGS="-DUSE_MGL_NAMESPACE" \
>      CFLAGS="-DUSE_MGL_NAMESPACE" \
>      ./configure \
>          --prefix `pwd`/build/Linux64 \
>          --enable-debug=no \
>          --disable-driglx-direct \
>          --enable-gl-osmesa=yes \
>          --disable-glw \
>          --disable-glut \
>          --with-driver=xlib \
>          --with-dri-drivers=  \
>          --with-osmesa-bits=32 \
>          --with-gallium-drivers= \
>          --disable-egl \
>          --enable-64-bit
>
>      gmake -j4
>      gmake install
>
>
> *Potential Issues*
>
> Mangling
>
>     I need to make some changes to *.def files on windows and make
>     other changes on Linux to ensure mangled mesa functioned the way I
>     expected. i.e. GLU uses mangled symbols and OSMesa and MesaGL did
>     not both export gl* procedures. I am not certain this is all
>     necessary however and I may just be creating work for my self.
>
> OSMesa
>
>     - I have a set of FrameBufferObject tests, which all failed with
>     the GDI driver, they were failing in 7.7.1 and they are still
>     failing with 7.11.2.
>     - I believe these is a memory problem specific to OSMesa, which is
>     triggered when a call to OSMesaDestroyContext is made after
>     OSMesaMakeCurrent has been called. I was unable to track down the
>     exact location of the problem. I had a look through the 8.* tree
>     to see if there was something I could backport, however I was
>     unable to locate such a change.
>

This is all really good info.  It would be nice to integrate this info 
into the Mesa documentation.  I recently updated the web page that 
describes how to build Mesa in various ways.  Maybe you could look 
into adding that info there.  The web pages can be found in the 
Mesa/docs/ directory.


> ----------------------------------------
>
>
> Brian, much like Bruno I would love to help the effort. The barrier I
> see right now is, if we contribute towards the build/test of a
> particular  configuration to ensure it builds and runs successfully,
> it is very difficult to tell what we are likely to have broken. The
> mesa project is vast and the number of possible combinations is large
> and growing.

Well, any changes you make should be posted as patches for review on 
the mesa-dev list.  Hopefully, people will be able to spot any changes 
that might break the build elsewhere.


> What I am getting at is what can we do to help set up
> continues verification of builds and tests such that we can easily
> identify the point of break?

I seem to recall someone was setting up automated building/testing of 
Mesa, but haven't heard anything in a while.  There's probably 
websites/servers somewhere that could host that.


> I believe to really encourage contributions, it has to be easy for
> anyone to make a change without the fear of what they may have broken
> elsewhere,  as far a I can tell we are not there yet.

Anyone is free to post patches to the mesa-dev list.  If they look 
good, they'll get applied.


> Finally - I want to say that I like many others am very appreciative
> of all the effort you and others put into the Mesa project, and I am
> very much looking forward to seeing Gallium and particularly the
> llvm-pipe driver reach its potential.

Thanks!

-Brian