Re: NEW: devel/creduce

[Brian Callahan]

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

use of the infrastructure.

This is exactly what I was worried about here:



From: Stuart Henderson <s...@spacehopper.org>
Date: Tue, 6 Mar 2018 12:47:07 +0000
To: Jonathan Gray <j...@jsg.id.au>

User-Agent: Mutt/1.9.3 (2018-01-21)
Subject: Re: build libLLVM.so in devel/llvm
Mail-Followup-To: Jonathan Gray <j...@jsg.id.au>, Brian Callahan
    <bcal...@devio.us>, ports@openbsd.org, b...@comstyle.com

On 2018/03/06 21:32, Jonathan Gray wrote:

devel/llvm to force a tight dependency on the version but it's not correct ----- Forwarded message from Stuart Henderson <s...@spacehopper.org> ----- Cc: Brian Callahan <bcal...@devio.us>, ports@openbsd.org, b...@comstyle.com

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

version in that case..

via SHARED_LIBS) the way we've got cmake setup it just skips the library

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.


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


$ llvm-config --link-shared
llvm-config: error: libLLVM-5.0.so is missing
$ llvm-config --shared-mode
static

Warning: symlink(s) point to non-existent /usr/ports/pobj/llvm-5.0.1/fake-amd64/usr/local/lib/libLLVM-5.0.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

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

an eye on it.


----- End forwarded message -----

the way of your work on Mesa, so OK sthen@ but think we will need to keep

Tarball reattached with some tweaks.


~Brian

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.

OK?

~Brian

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

creduce.tgz
Description: Binary data