Re: NEW: devel/creduce

On 04/15/18 04:01, Stuart Henderson wrote:
> On 2018/04/15 02:27, Brian Callahan wrote:
>> Works well on amd64 following the user guide on the HOMEPAGE. Note that this
>> links libLLVM-6.0.so from devel/llvm, though that does not get reflected in
>> WANTLIB (I left a comment saying such in the Makefile).
> You need to have a WANTLIB entry associated with the LIB_DEPENDS otherwise
> the LIB_DEPENDS is stripped.
>
> One way around it might be to use RUN_DEPENDS only and set PKGSPEC in
> devel/llvm to force a tight dependency on the version but it's not correct
> use of the infrastructure.
>
> This is exactly what I was worried about here:
>
> ----- Forwarded message from Stuart Henderson <stu@spacehopper.org> -----
>
> From: Stuart Henderson <stu@spacehopper.org>
> Date: Tue, 6 Mar 2018 12:47:07 +0000
> To: Jonathan Gray <jsg@jsg.id.au>
> Cc: Brian Callahan <bcallah@devio.us>, ports@openbsd.org, brad@comstyle.com
> User-Agent: Mutt/1.9.3 (2018-01-21)
> Subject: Re: build libLLVM.so in devel/llvm
> Mail-Followup-To: Jonathan Gray <jsg@jsg.id.au>, Brian Callahan
> <bcallah@devio.us>, ports@openbsd.org, brad@comstyle.com
>
> 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.
>
>
> ----- End forwarded message -----

Tarball reattached with some tweaks.
Now this will break immediately on a version update of devel/llvm, but that's ok for me; it'll force me to check to make sure everything still works.

~Brian