Re: llvm with pkgsrc libexecinfo

[Michael Forney <mforney%mforney.org@localhost>]

On 2020-09-06, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> Michael Forney <mforney%mforney.org@localhost> writes:
>
>> I've been able to work around this problem by adding
>>
>> 	.include "../../devel/libexecinfo/buildlink3.mk"
>>
>> to lang/llvm/Makefile. Is this the right solution or is there some way
>> to prevent cmake from detecting the pkgsrc libexecinfo?
>
> 1) One option is to do that, but given that libexecinfo seems builtin
> normally, there needs to be builtin.mk support so that the native
> version is used when present.  I haven't looked in this case, but this
> pattern is common in pkgsrc.

It looks like there is already builtin.mk support for libexecinfo, so
systems that have a native version would continue to use that one.

So it sounds like this is the ideal solution. llvm will always be
built with backtrace support, either through the system's native
version if it is available, or one installed through pkgsrc if it is
not.

> 2) Another approach is to find out why libexecinfo is in the buildlink
> tree; it seems that cmake as a tool shouldn't be pulling in things like
> that.

libexecinfo does not actually get added to the buildlink tree. The
problem is that cmake searches for libraries by their file names
rather than testing whether it can link with the library. This causes
it to find libexecinfo in the real /usr/pkg (it is there since cmake
is installed), but during compilation, /usr/pkg paths are stripped by
the wrapper, causing the build failure.

> 3) A third approach is to patch the llvm build to not ind it, but I suspect
> it is better for llvm to have it, not to turn it off.  It doesn't seem
> good to turn it off elsewhere, and it doesn't seem good to have it be
> different.
>
>
> So I would look into 1, and separately see if there is a bug as
> described in 2.

Thanks for your help!