On 3/6/2018 7:47 AM, Stuart Henderson wrote: > On 2018/03/06 21:32, Jonathan Gray wrote: >> On Sat, Feb 17, 2018 at 11:12:44PM +1100, Jonathan Gray wrote: >>> On Thu, Feb 15, 2018 at 05:08:56PM +0000, Stuart Henderson wrote: >>>> On 2018/02/15 11:19, Brian Callahan wrote: >>>>> On 02/15/18 10:02, Jonathan Gray wrote: >>>>>> Build libLLVM.so and link tools with it. >>>>>> >>>>>> This seems to be the way almost all Linux distributions and BSDs >>>>>> ship LLVM and is what Mesa expects. >>>>>> >>>>>> Use the documented cmake var for RTTI while here. >>>>> Any reason not to use the SHARED_LIBS facility of ports for libLLVM, like >>>>> libclang and libLTO already do in the LLVM port? >>>> agreed, it's a bit non-obvious that it might be needed because unlike >>>> other build systems (which normally use a default value if not passed >>>> via SHARED_LIBS) the way we've got cmake setup it just skips the library >>>> version in that case.. >>>> >>> Trying to use SHARED_LIBS breaks and isn't so useful as the name >>> of the library includes the major/minor llvm version with the abi >>> unlikely to change on new release based from the same branch. >>> >>> The intent seems to be to allow multiple versions to be installed >>> concurrently as llvm breaks abi/api between most releases. >>> >>> Warning: symlink(s) point to non-existent >>> /usr/ports/pobj/llvm-5.0.1/fake-amd64/usr/local/lib/libLLVM-5.0.so >>> /usr/ports/pobj/llvm-5.0.1/fake-amd64/usr/local/lib/libLLVM-5.0.1.so >>> /usr/ports/pobj/llvm-5.0.1/fake-amd64/usr/local/lib/libLLVM.so >>> >>> $ ls -l /usr/local/lib/libLLVM*.so* >>> lrwxr-xr-x 1 root wheel 14 Feb 17 22:55 >>> /usr/local/lib/libLLVM-5.0.1.so -> libLLVM-5.0.so >>> -rw-r--r-- 1 root bin 61453686 Feb 17 22:47 >>> /usr/local/lib/libLLVM-5.0.so.0.0 >>> lrwxr-xr-x 1 root wheel 14 Feb 17 22:55 /usr/local/lib/libLLVM.so >>> -> libLLVM-5.0.so >>> >>> $ llvm-config --link-shared >>> llvm-config: error: libLLVM-5.0.so is missing >>> $ llvm-config --shared-mode >>> static >> So would anyone be opposed to the first diff in this thread going in? > The potential issue with this is that if things in ports start linking > to it, we'll run into problems with updates. > > That said I don't really have a better idea and I don't want to get in > the way of your work on Mesa, so OK sthen@ but think we will need to keep > an eye on it. >
Same ok with me. Go ahead.
