[Mesa-users] RES: Error compiling 8.0.2 in Windows, and some support
Viral Patel
viral.patel at ansys.com
Fri May 4 01:28:44 PDT 2012
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(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.
----------------------------------------
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.
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 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.
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.
Thank you,
Viral
On 4 May 2012 01:06, Bruno Kim Medeiros Cesar <bruno.cesar at neolog.com.br>wrote:
> Thanks for your support, Brian!
>
> I didn't manage to build the 7.11.2 version because it lacks
> opengl32.mingw.def (as I recall from memory), but succeeded in building
> 7.10.x which has this *.def.
>
> Now there's another problem, maybe some of "other ways" you feel the driver
> may fail :) It tries to call a dxtn.dll, which is not present, do you know
> what it is?
>
> Tomorrow may be a luckier day,
>
> Bruno Kim.
>
> PS.: walking through the code I found a cpp with Lisp code that is
> processed
> by a custom builtin compiler... Can't say if it's awesome or frightening!
>
> -----Mensagem original-----
> De: Brian Paul [mailto:brianp at vmware.com]
> Enviada em: quinta-feira, 3 de maio de 2012 16:49
> Para: Bruno Kim Medeiros Cesar
> Cc: mesa-users at lists.freedesktop.org
> Assunto: Re: [Mesa-users] Error compiling 8.0.2 in Windows, and some
> support
>
> On 05/03/2012 12:41 PM, Bruno Kim Medeiros Cesar wrote:
> > Hello, all. I'm trying to build Mesa 8.0.2 in Windows 7, using
> >
> > scons platform=windows machine=x86 statetrackers=mesa winsys=gdi
> > build=release drivers=gdi,mesagdi,mesa,trace
> >
> > and bumped in the following error while compiling wmesa.c:
> >
> > Compiling src\mesa\drivers\windows\gdi\wmesa.c ...
> >
> > -- snip --
> >
> > Finished generating code
> >
> > scons: building terminated because of errors.
> >
> > The error is clear enough, I looked at the source and indeed there is
> > no function pointer member of gl_renderbuffer.
>
> Yeah, the windows driver hasn't had much attention lately. I'm
> cherry-picking some changes from Mesa master to the 8.0 branch to hopefully
> fix this problem for the next 8.0.x release. But I have a feeling that the
> driver may fail in other ways.
>
> You're probably best off going back to 7.12 or 7.11 release.
>
>
> > Sidenote 1: why not provide standalone DLLs?
>
> Nobody has volunteered to make/maintain them.
>
>
> > Sidenote 2: my need is solely software rendering, which drivers should
> > I pass to scons? And where is documented the available CLI arguments?
> > Statetrackers and winsys aren't documented at -h.
>
> The "osmesa" target will build the "Off-Screen" Mesa interface which
> doesn't
> use any wgl/glx entrypoingts.
>
>
> >
> > Sidenote 3: I will now try to build with windows as target in a Linux
> > environment, because the Windows build process requires a lot of Unix
> > dependencies - had to install MinGW, GnuWin32 and such. How could it
> > be minimized? I saw that you need help maintaining Windows driver
> > building, testing and maintenance, how could I help? Just checking out
> > the repo and testing new releases is enough, or more expertise is
> > required? I'm just a Java developer intern without much experience J
>
> Checking out the code and trying to fix build issues would be great.
>
> -Brian
>
> _______________________________________________
> mesa-users mailing list
> mesa-users at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-users/attachments/20120504/b0205022/attachment-0001.htm>
More information about the mesa-users
mailing list