<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 7, 2015 at 4:06 AM, Emil Velikov <span dir="ltr"><<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jon,<br>
<div><div class="h5"><br>
On 4 September 2015 at 14:00, Jon TURNEY <<a href="mailto:jon.turney@dronecode.org.uk">jon.turney@dronecode.org.uk</a>> wrote:<br>
> When checking for LLVM shared libraries, use IMP_LIB_EXT for the extension for<br>
> shared libraries appropriate to the target, rather than hardcoding '.so'<br>
><br>
> Also add some comments to explain why we have this circus of pain.<br>
><br>
> Signed-off-by: Jon TURNEY <<a href="mailto:jon.turney@dronecode.org.uk">jon.turney@dronecode.org.uk</a>><br>
> ---<br>
>  <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a> | 33 +++++++++++++++++++++++++++------<br>
>  1 file changed, 27 insertions(+), 6 deletions(-)<br>
><br>
> diff --git a/<a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a> b/<a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a><br>
> index 90ba4fe..9960dd0 100644<br>
> --- a/<a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a><br>
> +++ b/<a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a><br>
> @@ -533,15 +533,32 @@ AM_CONDITIONAL(HAVE_COMPAT_SYMLINKS, test "x$HAVE_COMPAT_SYMLINKS" = xyes)<br>
>  dnl<br>
>  dnl library names<br>
>  dnl<br>
> +dnl Unfortunately we need to do a few things that libtool can't help us with,<br>
> +dnl so we need some knowledge of shared library filenames:<br>
> +dnl<br>
> +dnl LIB_EXT is the extension used when creating symlinks for alternate<br>
> +dnl filenames for a shared library which will be dynamically loaded<br>
> +dnl<br>
> +dnl IMP_LIB_EXT is the extension used when checking for the presence of a<br>
> +dnl the file for a shared library we wish to link with<br>
> +dnl<br>
>  case "$host_os" in<br>
>  darwin* )<br>
> -    LIB_EXT='dylib' ;;<br>
> +    LIB_EXT='dylib'<br>
> +    IMP_LIB_EXT=$LIB_EXT<br>
> +    ;;<br>
>  cygwin* )<br>
> -    LIB_EXT='dll' ;;<br>
> +    LIB_EXT='dll'<br>
> +    IMP_LIB_EXT='dll.a'<br>
> +    ;;<br>
>  aix* )<br>
> -    LIB_EXT='a' ;;<br>
> +    LIB_EXT='a'<br>
> +    IMP_LIB_EXT=$LIB_EXT<br>
> +    ;;<br>
>  * )<br>
> -    LIB_EXT='so' ;;<br>
> +    LIB_EXT='so'<br>
> +    IMP_LIB_EXT=$LIB_EXT<br>
> +    ;;<br>
>  esac<br>
><br>
>  AC_SUBST([LIB_EXT])<br>
> @@ -2163,10 +2180,14 @@ if test "x$MESA_LLVM" != x0; then<br>
><br>
>      LLVM_LIBS="`$LLVM_CONFIG --libs ${LLVM_COMPONENTS}`"<br>
><br>
> +    dnl llvm-config may not give the right answer when llvm is a built as a<br>
> +    dnl single shared library, so we must work the library name out for<br>
> +    dnl ourselves.<br>
> +    dnl (See <a href="https://llvm.org/bugs/show_bug.cgi?id=6823" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=6823</a>)<br>
>      if test "x$enable_llvm_shared_libs" = xyes; then<br>
>          dnl We can't use $LLVM_VERSION because it has 'svn' stripped out,<br>
>          LLVM_SO_NAME=LLVM-`$LLVM_CONFIG --version`<br>
> -        AS_IF([test -f "$LLVM_LIBDIR/lib$LLVM_SO_NAME.so"], [llvm_have_one_so=yes])<br>
> +        AS_IF([test -f "$LLVM_LIBDIR/lib$LLVM_SO_NAME.$IMP_LIB_EXT"], [llvm_have_one_so=yes])<br>
><br>
>          if test "x$llvm_have_one_so" = xyes; then<br>
>              dnl LLVM was built using auto*, so there is only one shared object.<br>
> @@ -2174,7 +2195,7 @@ if test "x$MESA_LLVM" != x0; then<br>
>          else<br>
>              dnl If LLVM was built with CMake, there will be one shared object per<br>
>              dnl component.<br>
> -            AS_IF([test ! -f "$LLVM_LIBDIR/libLLVMTarget.so"],<br>
> +            AS_IF([test ! -f "$LLVM_LIBDIR/libLLVMTarget.$IMP_LIB_EXT"],<br>
</div></div>Fwiw I would prefer if we drop support for non have_one_so file LLVM<br>
builds and just fail miserably, rather than having this around :-)<br>
I suspect that either a) llvm people may have dropped support for it,<br>
b) it's tested/used extremely rarely or c) busted with latest<br>
llvm/mesa.<br>
<br></blockquote><div><br></div><div>FWIW, this still works just fine with current trunk LLVM.  I've been building clover for r600g and also mesa/clover for radeonsi using an exploded LLVM build (or whatever you want to call it) just fine for a while now.  I don't need to split out the separate sub-modules of LLVM for any reason, but that's how my cmake-based build script is configured to run.<br><br></div><div>--Aaron<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tom how do you feel on the subject ? Can we drop this workaround,<br>
pretty please (/me does the puppy eyes)<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">Emil<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br></div></div>