[Mesa-dev] Build failure since May 6

tom fogal tfogal at alumni.unh.edu
Mon May 10 10:30:28 PDT 2010


"Kevin H. Hobbs" <hobbsk at ohiou.edu> writes:
> On 05/10/2010 11:56 AM, tom fogal wrote:
> >=20
> > I recommend you check out the "build_mesa" function in:
> >=20
> >   http://portal.nersc.gov/svn/visit/trunk/src/svn_bin/build_visit
> >=20
> > There's a lot we can do to make the whole VTK, Mesa/mangled or no,
> > and VisIt/ParaView stack more amenable to compilation / easier to
> > get going.  Let me know if you are interested in dividing up some
> > of that work.
> >=20
> > Cheers,
> >=20
> > -tom
> >=20
> 
> The builds I submit to the VTK and ParaView dashboards all use Mesa
> and OSMesa without direct rendering as the only GL.
>
> These builds all use the make files included with Mesa and not the
> autoconf method.

I have found, and now you are finding, that these targets do not give
enough control.  I highly recommend an autoconf-based build.

> I've never had Mangled Mesa work with VTK.
>
> Nor have I had Mesa built with the configure scripts work on and off
> screen with VTK.

It is probably difficult, due to the way VTK mixes all of these
symbols in a single source file, thus necessitating a library that has
everything linked in.  This is one of the aforementioned issues that
needs addressed.

> I even remember some mess in a .spec file where mesa was built with
> DRI installed and then OSMesa was built and installed. That didn't
> work either.

Yes, I've seen issues mixing DRI-Mesa and our Mesa as well, but
unfortunately I don't have a system which uses DRI and haven't been
able to reproduce it myself.  It seems to me that duplicated symbols
end up causing execution to jump from one library to another.  I am
hoping the recent symbol visibility addition helps with this, and I had
started a branch to get exactly the correct symbols exported and no
more.. but I haven't had time to get back to it.

> If there's another way I'd love to hear it, and I'll do whatever I
> can to help.

The most useful thing that could be done is to separate out the OSMesa
code from vtkXOpenGLRenderWindow.  This would allow one to build a
libvtkRendering.so which does not need glX symbols, assuming there's a
cmake option to avoid building the X rendering path.

Doing so would obviate the need to build MesaGL, meaning 1) an
autoconf-based build could be done in 1 pass, 2) we would rely on less
Mesa code/build infrastructure, meaning these types of build failures
would be less relevant/frequent, and finally 3) there would be no need
for the unintuitive CMake hack I outline below.

> I'm sure I don't fully understand the build_mesa function in the
> build_visit script but it seems like it's doing name mangling and
> such to support accelerated onscreen and mesa offscreen rendering in
> a single VTK build.

Yep, exactly.

> All I really want is Mesa with OSMesa from the development repository
> as the "reference" library for my VTK and ParaView nightly test
> builds.

Exactly, you have the same use case as us.

In that case, you really only want to build OSMesa, but because of VTK,
you'll need MesaGL as well.  The trick is to tell VTK that your MesaGL
library is OSMesa and your OSMesa library is MesaGL.  This will cause
CMake to link "-lOSMesa -lMesaGL"; if you reverse the process then you
end up using the wrong symbols in the offscreen case.


I think we've strayed off-topic; future replies should probably be
private.

Cheers,

-tom


More information about the mesa-dev mailing list