Re: NEW: devel/creduce

On 06/03/18 19:23, Brian Callahan wrote:
>
> 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
>

New tarball. Relax llvm check slightly--checking between 6.0 and 6.1
instead of 6.0.0 and 6.0.1

OK?

~Brian