On 27/10/14 21:03, Jan Vesely wrote: > On Mon, 2014-10-27 at 20:22 +0000, Emil Velikov wrote: >> 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 <k...@dev.carbon-project.org> >>>>>>> CC: Emil Velikov <emil.l.veli...@gmail.com> >>>>>>> Signed-off-by: Jan Vesely <jan.ves...@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. > > looks like misdesign on llvm side. they use public to bring systemlibs > to other llvm libs, while ignore private deps elsewhere (like libffi). > I'd try to send a patch, but my last attempt to get Alexander's rtti > patch in is stuck for 9 months... > Yes, dealing with build systems is a job no-one wants to do, and I fear most people underestimate it. Please let them know and be persistent otherwise they might will end up abusing it too much :)
> anyway, since we only need those libs in static builds, do you want me > to repost the patch with bug reference and Kai's tested by? > There is no problem. I've picked it up, added the tags + cc'd mesa-stable, as I would expect a few more people willing to use mesa with static linked llvm. Thanks Emil > jan > >> >> >> -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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
