On Tue, Apr 19, 2016 at 07:39:13PM +0100, Emil Velikov wrote: > Hi Chuck, > > Thanks for chipping in. > > On 19 April 2016 at 15:47, Chuck Atkins <chuck.atk...@kitware.com> wrote: > > This still doesn't quite give what you want. One can also have an llvm with > > component shared libs. So there's three different options for llvm library > > configurations: a single shared lib, component shared libs, or component > > static libs. > From the three - only single shared lib and component static libs are > supported. > > Personally I'm leaning that we ought to go with the latter only... Esp > considering the problems that people tend to have with mesa + steam, > every so often. > > IIRC all the issues that we had with static llvm have been resolved. > Plus we have great people like Kai who promptly send patches when > things break (which hasn't happen in a long time) > > Tom, what is your view on the topic - are you ok with us switching > back to static one and/or nuking the shared one ? Iirc Jose was clear > that in his view one should just static link LLVM. I believe that's > still the case, right Jose ? >
The shared option is useful for development, because then you don't need to rebuild mesa every time you make an LLVM change, so I don't want to remove it. I don't really have a strong opinion of what should be default. Static libraries have the disadvantage of requiring you to explicitly list the libraries you need, so if a library changes names or a new dependency is added, the build will break. Static libraries builds also take up a huge amount of disk/memory since each pipe driver and state tracker has their own copy of LLVM linked in. -Tom > Dave, I believe you guys were building with static llvm and/or private > version explicitly for mesa. Would shifting to static LLVM be an > option for you guys ? > > > To ensure you're getting just the static libs or just the > > shared libs, you'll need to wrap the link lines in -Bstatic or -Bdynamic. > > Something like (in pseudo code, not actual make or autoconf syntax): > > > > if use_llvm > > then > > if use_llvm_shared > > then > > if single_library > > then > > # (whatever logic you need to deal with the different library naming > > issues) > > LLVM_LIBS="-lLLVM'" or LLVM_LIBS="-LLVM-3.7" > > else # use llvm component libs > > LLVM_LIBS="-Wl,--push-state,-Bdynamic `$LLVM_CONFIG --libs > > $LLVM_COMPONENTS` -Wl,--pop-state" > > endif > > else # use_llvm_static > > LLVM_LIBS="-Wl,--push-state,-Bstatic `$LLVM_CONFIG --libs > > $LLVM_COMPONENTS` -Wl,--pop-state" > > endif > > > So far we did not need to have the -Bstatic/-Bdynamic as LLVM as of > recently introduced the experimental option of multiple shared > libraries. I guess that will lead to confusion as it gets more common > (less experimental) > > > LLVM_LIBS="-L`$LLVM_CONFIG --libdir` $LLVM_LIBS" > > endif > > > > - Chuck > > > > On Mon, Apr 18, 2016 at 11:01 PM, Jonathan Gray <j...@jsg.id.au> wrote: > >> > >> This patch is still required for master. > >> > >> On Sun, Feb 28, 2016 at 02:47:03PM +1100, Jonathan Gray wrote: > >> > When building with --disable-llvm-shared-libs use llvm-config --libfiles > >> > instead of of --libs so the full path to the .a files is used instead of > >> > -lname. > >> > > I would imagine that the issue here is cause because the llvm > libraries are not in the standard location correct ? I.e. they are > places somewhere like /usr/lib/llvm while the linker looks only in > /usr/lib. > > Personally I'm fine with the using --libnames when static linking, but > I'd appreciate if we can check that different versions of llvm-config > produce the same (correct) output throughout. > Based on the llvm-config code --libnames exists since 3.3.0 (at least) > so that's great. Running 3.7 and it's fine, although I cannot test > other versions, can anyone else it a try ? > > * OpenCL - 3.5.0 > * r300 - 'any' (3.3.0) LLVM > This should be demoted to a warning and a big fat note should be added > in the GL_VERSION string... But that's another topic > * r600/radeonsi - 3.6.0 > * swr 3.6.0 > * llvmpipe - 3.3.0 > > Thanks > Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
