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...

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?

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
> >>>>>  
> >>>>>
> >>>>
> >>>
> >>
> > 
> 

-- 
Jan Vesely <jan.ves...@rutgers.edu>

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to