[Mesa-dev] [PATCH] configure.ac: fix the --disable-llvm-shared-libs build

[Tom Stellard]

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.atkins at 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 <jsg at 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