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

[Emil Velikov]

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 ?

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