Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Jan Vesely]

On Mon, 2017-08-14 at 17:11 +0900, Michel Dänzer wrote:
> On 11/08/17 02:13 AM, Jan Vesely wrote:
> > On Thu, 2017-08-10 at 17:45 +0100, Emil Velikov wrote:
> > > 
> > > Topic for another thread:
> > > There's been a handful of issues reported with BUILD_SHARED_LIBS=ON.
> > > Should we consider that unsupported setup and error out?
> 
> I don't really see the point / gain in that.
> 
> 
> > please no.
> > BUILD_SHARED_LIBS=ON is a must for development setup
> > debug build of clang + llvm takes 1.4GB, each. Having a ~2.8GB library,
> > is a really bad idea for testing,
> 
> Not sure what testing you're referring to exactly, but IME application
> startup takes on the order of hundreds of ms longer when linking against
> the individual shared libraries than when linking against the single
> one. It's one reason why distros building with BUILD_SHARED_LIBS=ON is
> just silly.
> 
> 
> > not to mention linking time that goes well into minutes for even a
> > minor change in LLVM.
> 
> It can certainly take a long time, but I don't remember it taking
> minutes. Are you counting the time for linking other libraries / tools
> against libLLVM-*.0*.so as well? You can avoid that by explicitly
> building only the library, e.g.:
> 
>  ninja [...] lib/libLLVM-6.0svn.so
> 
> Also, using the gold or lld linker might help.

The problem is that setting both
BUILD_SHARED_LIBS=ON
LLVM_BUILD_LLVM_DYLIB=ON
Does not work.

BUILD_SHARED_LIBS=OFF results in every component creating its own
static library. These are used be default when linking LLVM tools. This
configuration results in 15G build/lib and another 15G build/bin.

simple test:
touch lib/Target/AMDGPU/R600ISelLowering.cpp
make -j3 (using more jobs exhausts available memory since a linking
process easily takes 7-9GB).
takes ~15mins to complete, and that's without the install step.

using LLVM_LINK_LLVM_DYLIB=ON improves the test time to ~7m (and
reduces build/bin to ~4GB)

but it still does not compare to ~40s that it takes BUILD_SHARED_LIBS
to finish the same test.

Jan




signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Michel Dänzer]

On 15/08/17 07:55 AM, Grazvydas Ignotas wrote:
> On Mon, Aug 14, 2017 at 11:13 PM, Andy Furniss  wrote:
>> Michel Dänzer wrote:
>>>
>>> On 11/08/17 01:45 AM, Emil Velikov wrote:
>>>
>>> Thanks, pushed.
>>
>>
>> Don't know if this is expected or not, but llvm built like -
>>
>> cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
>> -DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON
>> -DLLVM_APPEND_VC_REV=OFF -DLLVM_BUILD_LLVM_DYLIB=ON
>>
>> now fails to build mesa (I also tried without vulkan and it still fails
>> raseonsi IIRC).
>>
>>  CXXLDlibvulkan_radeon.la
>> /usr/lib/libLLVMSupport.a(Process.cpp.o): In function
>> `llvm::sys::Process::FileDescriptorHasColors(int)':
>> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x4d):
>> undefined reference to `setupterm'
>> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x78):
>> undefined reference to `tigetnum'
>> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x81):
>> undefined reference to `set_curterm'
>> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x89):
>> undefined reference to `del_curterm'
>> collect2: error: ld returned 1 exit status
>>
>> Haven't tried llvm with -DLLVM_APPEND_VC_REV=ON yet, mesa still builds OK
>> with this commit reverted.
> 
> Same problem here, using LLVM-6.0 from a week ago, my cmake is just
> -DCMAKE_INSTALL_PREFIX=/opt/xorg -DLLVM_TARGETS_TO_BUILD='AMDGPU;X86'
> -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=TRUE
> 
> llvm-config --libs
> seems to return tons of output like -lLLVMBitWriter -lLLVMAnalysis
> -lLLVMProfileData -lLLVMObject ... which seems to result in static
> linking that's supposedly not supported by mesa? The only .so I see is
> libLLVM.so , all others are .a files.
> 
> Meanwhile
> llvm-config --shared-mode
> returns "static", which implies it wants be statically linked. There
> is BUILD_SHARED_LIBS cmake option, but llvm documentation advices
> against using it and suggests LLVM_BUILD_LLVM_DYLIB instead.
> Confusing...
> 
> Also, llvm-config --version says "6.0.0git-f49c401", which means I had
> to manually hack configure.ac every time to "6.0.0svn" to get mesa
> building too :(

The patch was intended to fix that issue, but it only works if LLVM is
built with -DLLVM_LINK_LLVM_DYLIB=ON.

Thanks for the report, followup patch posted for review.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Grazvydas Ignotas]

On Tue, Aug 15, 2017 at 1:55 AM, Grazvydas Ignotas  wrote:
>
> Also, llvm-config --version says "6.0.0git-f49c401", which means I had
> to manually hack configure.ac every time to "6.0.0svn" to get mesa
> building too :(

Nevermind about this one, -DLLVM_APPEND_VC_REV=OFF solves it. Would be
great to have a "how to configure llvm for mesa" section somewhere.

Gražvydas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Grazvydas Ignotas]

On Mon, Aug 14, 2017 at 11:13 PM, Andy Furniss  wrote:
> Michel Dänzer wrote:
>>
>> On 11/08/17 01:45 AM, Emil Velikov wrote:
>>
>> Thanks, pushed.
>
>
> Don't know if this is expected or not, but llvm built like -
>
> cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
> -DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON
> -DLLVM_APPEND_VC_REV=OFF -DLLVM_BUILD_LLVM_DYLIB=ON
>
> now fails to build mesa (I also tried without vulkan and it still fails
> raseonsi IIRC).
>
>  CXXLDlibvulkan_radeon.la
> /usr/lib/libLLVMSupport.a(Process.cpp.o): In function
> `llvm::sys::Process::FileDescriptorHasColors(int)':
> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x4d):
> undefined reference to `setupterm'
> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x78):
> undefined reference to `tigetnum'
> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x81):
> undefined reference to `set_curterm'
> Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x89):
> undefined reference to `del_curterm'
> collect2: error: ld returned 1 exit status
>
> Haven't tried llvm with -DLLVM_APPEND_VC_REV=ON yet, mesa still builds OK
> with this commit reverted.

Same problem here, using LLVM-6.0 from a week ago, my cmake is just
-DCMAKE_INSTALL_PREFIX=/opt/xorg -DLLVM_TARGETS_TO_BUILD='AMDGPU;X86'
-DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=TRUE

llvm-config --libs
seems to return tons of output like -lLLVMBitWriter -lLLVMAnalysis
-lLLVMProfileData -lLLVMObject ... which seems to result in static
linking that's supposedly not supported by mesa? The only .so I see is
libLLVM.so , all others are .a files.

Meanwhile
llvm-config --shared-mode
returns "static", which implies it wants be statically linked. There
is BUILD_SHARED_LIBS cmake option, but llvm documentation advices
against using it and suggests LLVM_BUILD_LLVM_DYLIB instead.
Confusing...

Also, llvm-config --version says "6.0.0git-f49c401", which means I had
to manually hack configure.ac every time to "6.0.0svn" to get mesa
building too :(

Gražvydas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Andy Furniss]

Michel Dänzer wrote:

On 11/08/17 01:45 AM, Emil Velikov wrote:

On 9 August 2017 at 02:00, Michel Dänzer  wrote:

On 09/08/17 03:24 AM, Emil Velikov wrote:


I think we'd want to keep the best of both - just not sure how to
exactly do that.
--libs/--libfiles was completely busted with LLVM 3.9 and is back to
normal with 4.0.

Could we use that somehow?


This patch relies on llvm-config --libs with LLVM >= 4.0. If you mean
something else, please be more specific.


That's the thing - in some versions --libs is busted while for others
--libs/--libfiles.


Do you have any specific information about --libs being broken with
recent versions of LLVM? I though that was fixed long ago.



That said, patch does exactly what it says on the
Reviewed-by: Emil Velikov 


Thanks, pushed.


Don't know if this is expected or not, but llvm built like -

cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release 
-DLLVM_TARGETS_TO_BUILD="host;AMDGPU" -DLLVM_ENABLE_ASSERTIONS=ON 
-DLLVM_APPEND_VC_REV=OFF -DLLVM_BUILD_LLVM_DYLIB=ON


now fails to build mesa (I also tried without vulkan and it still fails 
raseonsi IIRC).


 CXXLDlibvulkan_radeon.la
/usr/lib/libLLVMSupport.a(Process.cpp.o): In function 
`llvm::sys::Process::FileDescriptorHasColors(int)':
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x4d): 
undefined reference to `setupterm'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x78): 
undefined reference to `tigetnum'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x81): 
undefined reference to `set_curterm'
Process.cpp:(.text._ZN4llvm3sys7Process23FileDescriptorHasColorsEi+0x89): 
undefined reference to `del_curterm'

collect2: error: ld returned 1 exit status

Haven't tried llvm with -DLLVM_APPEND_VC_REV=ON yet, mesa still builds 
OK with this commit reverted.


My mesa config =

./autogen.sh --prefix=/usr --sysconfdir=/etc --enable-texture-float 
--enable-opencl --enable-omx --with-egl-platforms=x11,drm,wayland 
--with-gallium-drivers=radeonsi,swrast --with-vulkan-drivers=radeon 
--enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers=


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Michel Dänzer]

On 11/08/17 02:13 AM, Jan Vesely wrote:
> On Thu, 2017-08-10 at 17:45 +0100, Emil Velikov wrote:
>>
>> Topic for another thread:
>> There's been a handful of issues reported with BUILD_SHARED_LIBS=ON.
>> Should we consider that unsupported setup and error out?

I don't really see the point / gain in that.


> please no.
> BUILD_SHARED_LIBS=ON is a must for development setup
> debug build of clang + llvm takes 1.4GB, each. Having a ~2.8GB library,
> is a really bad idea for testing,

Not sure what testing you're referring to exactly, but IME application
startup takes on the order of hundreds of ms longer when linking against
the individual shared libraries than when linking against the single
one. It's one reason why distros building with BUILD_SHARED_LIBS=ON is
just silly.


> not to mention linking time that goes well into minutes for even a
> minor change in LLVM.

It can certainly take a long time, but I don't remember it taking
minutes. Are you counting the time for linking other libraries / tools
against libLLVM-*.0*.so as well? You can avoid that by explicitly
building only the library, e.g.:

 ninja [...] lib/libLLVM-6.0svn.so

Also, using the gold or lld linker might help.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Michel Dänzer]

On 11/08/17 01:45 AM, Emil Velikov wrote:
> On 9 August 2017 at 02:00, Michel Dänzer  wrote:
>> On 09/08/17 03:24 AM, Emil Velikov wrote:
>>>
>>> I think we'd want to keep the best of both - just not sure how to
>>> exactly do that.
>>> --libs/--libfiles was completely busted with LLVM 3.9 and is back to
>>> normal with 4.0.
>>>
>>> Could we use that somehow?
>>
>> This patch relies on llvm-config --libs with LLVM >= 4.0. If you mean
>> something else, please be more specific.
>>
> That's the thing - in some versions --libs is busted while for others
> --libs/--libfiles.

Do you have any specific information about --libs being broken with
recent versions of LLVM? I though that was fixed long ago.


> That said, patch does exactly what it says on the
> Reviewed-by: Emil Velikov 

Thanks, pushed.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Jan Vesely]

On Thu, 2017-08-10 at 17:45 +0100, Emil Velikov wrote:
> On 9 August 2017 at 02:00, Michel Dänzer  wrote:
> > On 09/08/17 03:24 AM, Emil Velikov wrote:
> > > On 8 August 2017 at 08:23, Michel Dänzer  wrote:
> > > > From: Michel Dänzer 
> > > > 
> > > > No need to manually look for the library files anymore with current
> > > > LLVM. This sidesteps the manual method failing when LLVM was built with
> > > > -DLLVM_APPEND_VC_REV=ON.
> > > > 
> > > 
> > > IIRC you recently spotted that the Suse packaging was building LLVM
> > > with separate shared libraries.
> > 
> > Apparently that's getting fixed though.
> > 
> > 
> > > This is something which gets flagged with this (admittedly) quirky test.
> > 
> > What do you mean by that?
> > 
> > I just double-checked that Mesa with this patch still builds fine
> > against LLVM built with BUILD_SHARED_LIBS=ON, just like without it.
> > 
> 
> Right, I miss-remembered what the else block does.
> Thanks for the correction.
> 
> Topic for another thread:
> There's been a handful of issues reported with BUILD_SHARED_LIBS=ON.
> Should we consider that unsupported setup and error out?

please no.
BUILD_SHARED_LIBS=ON is a must for development setup
debug build of clang + llvm takes 1.4GB, each. Having a ~2.8GB library,
is a really bad idea for testing, not to mention linking time that goes
well into minutes for even a minor change in LLVM.

Jan

> 
> > 
> > > I think we'd want to keep the best of both - just not sure how to
> > > exactly do that.
> > > --libs/--libfiles was completely busted with LLVM 3.9 and is back to
> > > normal with 4.0.
> > > 
> > > Could we use that somehow?
> > 
> > This patch relies on llvm-config --libs with LLVM >= 4.0. If you mean
> > something else, please be more specific.
> > 
> 
> That's the thing - in some versions --libs is busted while for others
> --libs/--libfiles.
> There isn't a thing we could reliably check across the board, so I was
> hoping you know of something.
> 
> That said, patch does exactly what it says on the
> Reviewed-by: Emil Velikov 
> 
> -Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Emil Velikov]

On 9 August 2017 at 02:00, Michel Dänzer  wrote:
> On 09/08/17 03:24 AM, Emil Velikov wrote:
>> On 8 August 2017 at 08:23, Michel Dänzer  wrote:
>>> From: Michel Dänzer 
>>>
>>> No need to manually look for the library files anymore with current
>>> LLVM. This sidesteps the manual method failing when LLVM was built with
>>> -DLLVM_APPEND_VC_REV=ON.
>>>
>> IIRC you recently spotted that the Suse packaging was building LLVM
>> with separate shared libraries.
>
> Apparently that's getting fixed though.
>
>
>> This is something which gets flagged with this (admittedly) quirky test.
>
> What do you mean by that?
>
> I just double-checked that Mesa with this patch still builds fine
> against LLVM built with BUILD_SHARED_LIBS=ON, just like without it.
>
Right, I miss-remembered what the else block does.
Thanks for the correction.

Topic for another thread:
There's been a handful of issues reported with BUILD_SHARED_LIBS=ON.
Should we consider that unsupported setup and error out?

>
>> I think we'd want to keep the best of both - just not sure how to
>> exactly do that.
>> --libs/--libfiles was completely busted with LLVM 3.9 and is back to
>> normal with 4.0.
>>
>> Could we use that somehow?
>
> This patch relies on llvm-config --libs with LLVM >= 4.0. If you mean
> something else, please be more specific.
>
That's the thing - in some versions --libs is busted while for others
--libs/--libfiles.
There isn't a thing we could reliably check across the board, so I was
hoping you know of something.

That said, patch does exactly what it says on the
Reviewed-by: Emil Velikov 

-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Michel Dänzer]

On 09/08/17 03:24 AM, Emil Velikov wrote:
> On 8 August 2017 at 08:23, Michel Dänzer  wrote:
>> From: Michel Dänzer 
>>
>> No need to manually look for the library files anymore with current
>> LLVM. This sidesteps the manual method failing when LLVM was built with
>> -DLLVM_APPEND_VC_REV=ON.
>>
> IIRC you recently spotted that the Suse packaging was building LLVM
> with separate shared libraries.

Apparently that's getting fixed though.


> This is something which gets flagged with this (admittedly) quirky test.

What do you mean by that?

I just double-checked that Mesa with this patch still builds fine
against LLVM built with BUILD_SHARED_LIBS=ON, just like without it.


> I think we'd want to keep the best of both - just not sure how to
> exactly do that.
> --libs/--libfiles was completely busted with LLVM 3.9 and is back to
> normal with 4.0.
> 
> Could we use that somehow?

This patch relies on llvm-config --libs with LLVM >= 4.0. If you mean
something else, please be more specific.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Emil Velikov]

On 8 August 2017 at 08:23, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> No need to manually look for the library files anymore with current
> LLVM. This sidesteps the manual method failing when LLVM was built with
> -DLLVM_APPEND_VC_REV=ON.
>
IIRC you recently spotted that the Suse packaging was building LLVM
with separate shared libraries.
This is something which gets flagged with this (admittedly) quirky test.

Quick look [1] shows that Gentoo still uses separate shared libs :-\

I think we'd want to keep the best of both - just not sure how to
exactly do that.
--libs/--libfiles was completely busted with LLVM 3.9 and is back to
normal with 4.0.

Could we use that somehow?
-Emil

[1] 
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/llvm/llvm-4.0.1.ebuild
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure: Trust LLVM >= 4.0 llvm-config --libs for shared libraries

[Marek Olšák]

Acked-by: Marek Olšák 

Marek

On Tue, Aug 8, 2017 at 9:23 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> No need to manually look for the library files anymore with current
> LLVM. This sidesteps the manual method failing when LLVM was built with
> -DLLVM_APPEND_VC_REV=ON.
>
> (This might already work with older versions of LLVM)
>
> Signed-off-by: Michel Dänzer 
> ---
>  configure.ac | 58 ++
>  1 file changed, 30 insertions(+), 28 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 5b12dd8506..4992e9538f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2623,35 +2623,37 @@ if test "x$enable_llvm" = xyes; then
>  fi
>  LLVM_LIBS="`$LLVM_CONFIG --libs ${LLVM_COMPONENTS}`"
>
> -dnl llvm-config may not give the right answer when llvm is a built as a
> -dnl single shared library, so we must work the library name out for
> -dnl ourselves.
> -dnl (See https://llvm.org/bugs/show_bug.cgi?id=6823)
>  if test "x$enable_llvm_shared_libs" = xyes; then
> -dnl We can't use $LLVM_VERSION because it has 'svn' stripped out,
> -LLVM_SO_NAME=LLVM-`$LLVM_CONFIG --version`
> -AS_IF([test -f "$LLVM_LIBDIR/lib$LLVM_SO_NAME.$IMP_LIB_EXT"], 
> [llvm_have_one_so=yes])
> -
> -if test "x$llvm_have_one_so" = xyes; then
> -dnl LLVM was built using auto*, so there is only one shared 
> object.
> -LLVM_LIBS="-l$LLVM_SO_NAME"
> -else
> -dnl If LLVM was built with CMake, there will be one shared 
> object per
> -dnl component.
> -AS_IF([test ! -f "$LLVM_LIBDIR/libLLVMTarget.$IMP_LIB_EXT"],
> -[AC_MSG_ERROR([Could not find llvm shared libraries:
> -   Please make sure you have built llvm with the --enable-shared option
> -   and that your llvm libraries are installed in $LLVM_LIBDIR
> -   If you have installed your llvm libraries to a different directory you
> -   can use the --with-llvm-prefix= configure flag to specify this 
> directory.
> -   NOTE: Mesa is attempting to use llvm shared libraries by default.
> -   If you do not want to build with llvm shared libraries and instead 
> want to
> -   use llvm static libraries then add --disable-llvm-shared-libs to your 
> configure
> -   invocation and rebuild.])])
> -
> -   dnl We don't need to update LLVM_LIBS in this case because the 
> LLVM
> -   dnl install uses a shared object for each component and we have
> -   dnl already added all of these objects to LLVM_LIBS.
> +if test $LLVM_VERSION_MAJOR -lt 4; then
> +dnl llvm-config may not give the right answer when llvm is a 
> built as a
> +dnl single shared library, so we must work the library name out 
> for
> +dnl ourselves.
> +dnl (See https://llvm.org/bugs/show_bug.cgi?id=6823)
> +dnl We can't use $LLVM_VERSION because it has 'svn' stripped out,
> +LLVM_SO_NAME=LLVM-`$LLVM_CONFIG --version`
> +AS_IF([test -f "$LLVM_LIBDIR/lib$LLVM_SO_NAME.$IMP_LIB_EXT"], 
> [llvm_have_one_so=yes])
> +
> +if test "x$llvm_have_one_so" = xyes; then
> +   dnl LLVM was built using auto*, so there is only one shared 
> object.
> +   LLVM_LIBS="-l$LLVM_SO_NAME"
> +else
> +dnl If LLVM was built with CMake, there will be one shared 
> object per
> +dnl component.
> +AS_IF([test ! -f "$LLVM_LIBDIR/libLLVMTarget.$IMP_LIB_EXT"],
> +  [AC_MSG_ERROR([Could not find llvm shared libraries:
> +   Please make sure you have built llvm with the 
> --enable-shared option
> +   and that your llvm libraries are installed in 
> $LLVM_LIBDIR
> +   If you have installed your llvm libraries to a 
> different directory you
> +   can use the --with-llvm-prefix= configure flag to 
> specify this directory.
> +   NOTE: Mesa is attempting to use llvm shared libraries 
> by default.
> +   If you do not want to build with llvm shared 
> libraries and instead want to
> +   use llvm static libraries then add 
> --disable-llvm-shared-libs to your configure
> +   invocation and rebuild.])])
> +
> +dnl We don't need to update LLVM_LIBS in this case because 
> the LLVM
> +dnl install uses a shared object for each component and we 
> have
> +dnl already added all of these objects to LLVM_LIBS.
> +fi
>  fi
>  else
>  AC_MSG_WARN([Building mesa with statically linked LLVM may cause 
> compilation issues])
> --
> 2.13.3
>
> ___
> mesa-dev