"Kevin H. Hobbs" <hob...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
