On Wed, Apr 24, 2013 at 09:54:02PM -0700, Jose Fonseca wrote: > ----- Original Message ----- > > On Wed, Apr 24, 2013 at 09:40:44PM +0200, Mathias Fröhlich wrote: > > > > > > Hi Tom, > > > > > > On Tuesday, April 23, 2013 20:47:24 Tom Stellard wrote: > > > > First of all, thanks for investigating this. The information you've > > > > provided has helped me a lot. > > > Good to hear that it helps. > > > > > > > I took a shot at implementing it this way with private static copies of > > > > llvm. I've pushed the initial work to this branch: > > > > git://people.freedesktop.org/~tstellar/mesa llvm-build > > > > > > > > I was able to hide the LLVM symbols by using the --exclude-libs linker > > > > flag and so far I've tested with glxgears, an opencl example and also > > > > eglgears and they all work. I still need to do some more testing, but > > > > any thoughts on what I've done so far in this branch? > > > > > > I will look at this as soon as I find time. Probably not before the > > > beginning > > > of next week. > > > > > > > I've thought about this some more, and I think that the best solution > > might be to move all LLVM API calls into gallivm and build it as a > > shared object with it's own private copy of LLVM statically linked. This > > way > > we > > would still have a private copy of LLVM to work with, but without having > > to statically link every single gallium target with LLVM. Any thoughts > > about this? > > I don't see how this would work -- llvmpipe/draw has LLVMBuildXxxx calls too. > So to prevent symbol collision with apps that use them, we'd need to expose > all LLVM calls we need under nome unique prefix. >
I didn't realize this, and actually the radeon drivers use a lot of the LLVMBuildXxxx calls too. > Also note that gallivm has a lot of function calls. This would also pollute > the app's namespace. > > In short, for this to work we should do it not for whole gallivm, but with a > new module, just for LLVM C calls + the additional helpers, and use an unique > prefix (e.g., MesaLLVMXxxx) for everything. > > And we should have a new header, that #defines LLVMFoo MesaLLVMFoo, so that > Mesa code doesn't need to be changed all over the place. > I think this is a good approach, however before we make big changes to Mesa I want to make sure we know what problems we are trying to solve with these changes. As far as I understand it, the current problems are: 1. If an application is using the LLVM API outside of Mesa, then it is impossible for Mesa to safely use the llvm_*_multithreaded() functions. 2. If an application is using a different version of LLVM than Mesa, then it might incorrectly use the LLVM symbols that are included in the Mesa libraries. Are there others? -Tom _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
