pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/47284: wm/awesome & execinfo.h -- compilation failure
The following reply was made to PR pkg/47284; it has been noted by GNATS.
From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
Subject: Re: pkg/47284: wm/awesome & execinfo.h -- compilation failure
Date: Sun, 9 Dec 2012 18:40:33 +0000
On Tue, Dec 04, 2012 at 09:20:01PM +0000, Ephaeton%gmx.net@localhost wrote:
> wm/awesome doesn't build.
> [ 3%] Built target generated_sources
> [ 4%] Building C object CMakeFiles/awesome.dir/common/backtrace.c.o
> /space/obj/wm/awesome/work/awesome-3.4.13/common/backtrace.c:26:22:
fatal error: execinfo.h: No such file or directory
> compilation terminated.
So, it seems that the package tells cmake to check for the execinfo
library but not the header file. Is there something in your
environment that would lead it to find the library but not the header?
To complicate things, libexecinfo is in -current but not -6, so I
can't easily test any of this myself. But since it's not in -6, and
the package doesn't buildlink one in, in theory there shouldn't be an
execinfo library anywhere the configure logic should see it.
My guess is that if you already had wip/libexecinfo installed, cmake
went groping directly in /usr/pkg, found the library there, decided it
should use it, and then croaked because it wasn't buildlinked. Is
there any cmake config or log info you can find to support or refute
this hypothesis?
also, what do you get if the package finds libexecinfo? If it's not
worth much, the path of least resistance is probably to forcibly
disable libexecinfo in cmake.
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index