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