<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">Il 23/ago/2017 19:57, "Rob Herring" <<a href="mailto:robh@kernel.org">robh@kernel.org</a>> ha scritto:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On Wed, Aug 23, 2017 at 12:31 PM, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> wrote:<br> > On 23 August 2017 at 17:50, Rob Herring <<a href="mailto:robh@kernel.org">robh@kernel.org</a>> wrote:<br> >> On Sun, Aug 20, 2017 at 2:57 PM, Rob Herring <<a href="mailto:robh@kernel.org">robh@kernel.org</a>> wrote:<br> >>> On Fri, Aug 18, 2017 at 8:53 PM, Chih-Wei Huang <<a href="mailto:cwhuang@android-x86.org">cwhuang@android-x86.org</a>> wrote:<br> >>>> 2017-08-19 8:27 GMT+08:00 Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>>:<br> >>>>> On 18 August 2017 at 20:46, Rob Herring <<a href="mailto:robh@kernel.org">robh@kernel.org</a>> wrote:<br> >>>>>> Both statically linking libLLVMCore and dynamically linking libLLVM causes<br> >>>>>> duplicated symbols in gallium_dri.so and it fails to dlopen. We don't<br> >>>>>> really need to link libLLVMCore, but just need generated headers to be<br> >>>>>> built first. Dynamically linking to libLLVM instead is enough to do<br> >>>>>> that. Thanks to Qiang Yu for finding the root cause.<br> >><br> >> [...]<br> >><br> >>>>>> $(if $(filter 7,$(MESA_ANDROID_MAJOR_<wbr>VERSION)), \<br> >>>>>> - $(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0308 -DMESA_LLVM_VERSION_PATCH=0) \<br> >>>>>> - $(eval LOCAL_STATIC_LIBRARIES += libLLVMCore) \<br> >>>>>> - $(eval LOCAL_C_INCLUDES += external/llvm/include external/llvm/device/include),<wbr>) \<br> >>>>>> + $(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0308 -DMESA_LLVM_VERSION_PATCH=0),) \<br> >>>>>> $(if $(filter O,$(MESA_ANDROID_MAJOR_<wbr>VERSION)), \<br> >>>>>> - $(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0309 -DMESA_LLVM_VERSION_PATCH=0) \<br> >>>>>> - $(eval LOCAL_HEADER_LIBRARIES += llvm-headers),)<br> >>>>>> + $(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0309 -DMESA_LLVM_VERSION_PATCH=0),) \<br> >>>>>> + $(eval LOCAL_SHARED_LIBRARIES += libLLVM)<br> >>>>> Am I the only person getting tad confused by amount of brackets?<br> >>>>> As mentioned by Chih-Wei - a shell switch is not possible, but how<br> >>>>> about a test vague like the following?<br> >>>>><br> >>>>> test "x$(MESA_ANDROID_MAJOR_<wbr>VERSION)" = "xO" &&<br> >>>>> $(eval LOCAL_CFLAGS += -DHAVE_LLVM=0x0309 -DMESA_LLVM_VERSION_PATCH=0)<br> >>>><br> >>>> Only possible if you put it into $(shell ...)<br> >>>> That gives me an idea. Maybe we ca do like<br> >>>><br> >>>> $(shell case "$(MESA_ANDROID_MAJOR_VERSION)<wbr>" in \<br> >>>> 6) echo ... ;; \<br> >>>> 7) echo ... ;; \<br> >>>> *) echo ... ;; \<br> >>>> esac)<br> >>>><br> >>>> I haven't really try it yet.<br> >>><br> >>> What does either really buy us? It's really just bike shedding and<br> >>> unrelated to fixing the problem at hand.<br> >>><br> >>> I have another idea which is to use llvm-config and avoid the<br> >>> conditionals altogether. I haven't looked into that closely though.<br> >><br> >> Well, the build is broken again because the version changed from O to<br> >> 8 (and I'm not sure if master is going to change to P or 9 at some<br> >> point). So I went ahead and have this all coded up like this (I don't<br> >> see a simple way to build and run llvm-config):<br> >><br> > Yay :-(<br> ><br> >> $(eval $(shell sed -n -e<br> >> 's/.*$LLVM_VERSION_MAJOR$.*\<wbr>([0-9].*\)/\1:=\2/p'<br> >> external/llvm/device/include/<wbr>llvm/Config/llvm-config.h)) \<br> >> $(eval $(shell sed -n -e<br> >> 's/.*$LLVM_VERSION_MINOR$.*\<wbr>([0-9].*\)/\1:=\2/p'<br> >> external/llvm/device/include/<wbr>llvm/Config/llvm-config.h)) \<br> >> $(eval LOCAL_CFLAGS +=<br> >> -DHAVE_LLVM=0x$(LLVM_VERSION_<wbr>MAJOR)0$(LLVM_VERSION_MINOR))<br> >><br> >> Only one slight problem in that for master/O it reports 3.8 as the<br> >> version is 3.8.275480 which I think is the SVN version number. Not<br> >> sure what to do with that...<br> >><br> > Indeed, seems like a SVN version. Not sure how much to care about the<br> > PATCH version.<br> > Leave it as 0 or use the SVN one - your call.<br> <br> </div>Okay, I was a bit vague. The problem is the version is effectively 3.9<br> and the build breaks if we build with HAVE_LLVM=0x308 instead.<br> <br> I don't think it would work on older versions either. N has 3.8.256229<br> and that is 3.8 (from mesa perspective). The M version was 3.6.svn,<br> but we pass 3.7 to mesa. So there's not really a programmatic way to<br> handle this.<br> <font color="#888888"><br> Rob<br></font></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">LLVM version in Cmakelists.txt is indeed 3.9.0</div><div dir="auto">Mauro</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font color="#888888"> </font></blockquote></div><br></div></div></div>