Hi, On Wednesday, April 24, 2013 14:15:06 Tom Stellard wrote: > 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? That should work as well.
As the test program shows, you would need to make sure that no llvm native api symbol is visible outside of this library. That means you baiscally have to build an own abstraction layer around llvm. Than you are safe for llvm at least. More notes to that below. > > For now, I have attached the patch series I mentioned regarding dlopen > > flags which could be an other approach for this. I don't mind which > > approach you really take in the end. Anyway this appears to work up to > > now. It would have the advantage that it also helps other drivers beside > > r600g with the llvm issues and it would help much further for all the non > > static private symbols we have in the drivers. The series is running here > > in my private tree since about half a year. > > A few questions about the RTL_DEEPBIND patches: > > 1. Does this only work for linux? As far as I know yes. At first even only glibc like targets. So for android I don't know for example. And I don't have one available to look into at this moment. Anyway, I think the desire to have a stronger seperation of dynamically loaded modules to be more independent of prebuilt binaries is there - especially on bsd license based userspaces. So I assume that you see more than just linux offering this or a similar flag. Sadly the times that I had access to all sorts of unices at work is gone. So for example solaris10 has RTLD_GROUP which seems to be similar. Which operating systems do we care for as of today? Is amds or intels list longer than the current list of systems for mesa? > 2. Does RTL_DEEPBIND only make a difference if we are statically linking to > LLVM? As far as I understand this should also work for a shared llvm. You should really get an own instance of all the symbols in the shared object pulled by the .so you dlopen. This should include all statics and whatnot. The limitation would be to make sure that the driver shared object finds the correct llvm libraries. In face of LD_LIBRARY_PATH or similar being set to something application defined you could still get the one provided by an application bringing its own one. This would still help for the thread safe initialization problem, but for this case you will never know which api version you are going to pull and if this might work. But, if a (closed) application ships it's own llvm libraries - which is an appealing thought because of the still fast chaning llvm libraries - you can just run into this kind of problems with about any system library that pulls llvm under the hood. So this remaining problem is nothing we can really fix in mesa. But you proposal with a libgalliumllvm abstraction helps for gallium based llvm clashes then, since the library file is called different than libllvmwhatevernativename. In general, if you care for win32 targets with such a dynamic module structure, windows dynamic linking works somehow different than the linux one. But for this problem it's most notable that the default symbol visibility is set to hidden unless stated otherwise on win32. On *nix, you can see all symbols in a shared object unless explicitly marked hidden. So by default you get symbol clashes on *nix variants. But less of them on win32. By your proposal with having a libgalliumllvm, statically linked with llvm and only exporting non llvm native symbol names you would have cought this problem already on win32. Greetings Mathias _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
