[Mesa-dev] [PATCH WIP 1/1] configure: include llvm systemlibs when using static llvm

[Emil Velikov]

On 27/10/14 18:05, Jan Vesely wrote:
> On Mon, 2014-10-27 at 02:24 +0000, Emil Velikov wrote:
>> On 26/10/14 19:36, Jan Vesely wrote:
>>> On Fri, 2014-10-24 at 23:54 +0000, Emil Velikov wrote:
>>>> On 24/10/14 17:03, Jan Vesely wrote:
>>>>> -Wl,--exclude-libs prevents automatic export of symbols
>>>>>
>>>>>
>>>>> CC: Kai Wasserbach <kai at dev.carbon-project.org>
>>>>> CC: Emil Velikov <emil.l.velikov at gmail.com>
>>>>> Signed-off-by: Jan Vesely <jan.vesely at rutgers.edu>
>>>>> ---
>>>>>
>>>>> Kai,
>>>>> can you try this patch with your setup, and check whether LLVM symbols are
>>>>> exported from mesa library? (and it's still working)
>>>>>
>>>>> Emil,
>>>>> would it help to have --exclude-libs ALL enabled globally?
>>>>>
>>>> Haven't really looked up on the documentation about it, yet there should
>>>> be no (unneeded) exported symbols thanks to the version scripts.
>>>> As such I'm not entirely sure what this patch (attempts to) resolve :(
>>>
>>> you are right. I don't know why I thought it was still a problem.
>>> In that case the attached patch should fix compiling with llvm static
>>> libs (#70410)
>>>
>> For future patches please add the full link in the commit message
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70410
>>
>> Afaics the bug mentioned has a slightly different patch, which brings
>> the question - do we need to append to the existing LLVM_LIBS, or can we
>> overwrite them ? Either way it would be nice if we can get a tested-by
>> or two :)
> 
> Hi,
> 
> I looked at this again. LLVM cmake links system-libs as either PUBLIC or
> INTERFACE [0].
> it means my patch is incorrect, and we should link against system-libs
> even if we use llvm-shared-libs.
> you can add my R-b to the patch by K. Sobiecky that is attached to the
> bug.[1]
> 
Sigh... "cmake why you so PoS ?"

On a more mature note:
I do not see why would we need it to link against those libraries for
shared linking. If their libs are broken (have unresolved symbols), and
we need this hack to get them working then maybe, but
... looking at line 151 - # FIXME: Should this be really PUBLIC?
Answer: PRIVATE for shared libs, PUBLIC for static ones.

Using PUBLIC causes all the users to recursively link against those
deps. Leading to over-linking and opening the door for serious issues.


-Emil

P.S. Both their automake + cmake builds seems _quite_ bad.
autoconf/Readme has a nice documentation of it :)


> jan
> 
> 
> [0] lib/Support/CMakeLists.txt:150
> [1] https://bugs.freedesktop.org/attachment.cgi?id=91764
>>
>> Thanks
>> Emil
>>
>>> jan
>>>
>>>>
>>>> -Emil
>>>>
>>>>> jan
>>>>>
>>>>>  configure.ac | 10 +++++++++-
>>>>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/configure.ac b/configure.ac
>>>>> index 3c76deb..b4b4b13 100644
>>>>> --- a/configure.ac
>>>>> +++ b/configure.ac
>>>>> @@ -1981,7 +1981,15 @@ if test "x$MESA_LLVM" != x0; then
>>>>>             dnl already added all of these objects to LLVM_LIBS.
>>>>>          fi
>>>>>      else
>>>>> -        AC_MSG_WARN([Building mesa with staticly linked LLVM may cause compilation issues])
>>>>> +        AC_MSG_WARN([Building mesa with statically linked LLVM may cause compilation issues])
>>>>> +	dnl Don't export symbols automatically
>>>>> +	dnl TODO: Do we want to list llvm libs explicitly here?
>>>>> +	LLVM_LDFLAGS+=" -Wl,exclude-libs ALL"
>>>>> +	dnl We need to link to llvm system libs when using static libs
>>>>> +	dnl However, only llvm 3.5+ provides --system-libs
>>>>> +	if test $LLVM_VERSION_MAJOR -eq 3 -a $LLVM_VERSION_MINOR -ge 5; then
>>>>> +		LLVM_LIBS+=" `$LLVM_CONFIG --system-libs`"
>>>>> +	fi
>>>>>      fi
>>>>>  fi
>>>>>  
>>>>>
>>>>
>>>
>>
>