make buildworld fails in libdpv : ===> lib/libdpv (depend) rm -f .depend CC='cc ' mkdep -f .depend -a -I/usr/src/lib/libdpv -std=gnu99 /usr/src/lib/libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c /usr/src/lib/libdpv/dprompt.c /usr/src/lib/libdpv/dpv.c /usr/src/lib/libdpv/status.c /usr/src/lib/libdpv/util.c In file included from /usr/src/lib/libdpv/dialog_util.c:43: In file included from /usr/src/lib/libdpv/dialog_util.h:34: /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not found #include <figpar.h> ^ 1 error generated. /usr/src/lib/libdpv/dialogrc.c:34:10: fatal error: 'figpar.h' file not found #include <figpar.h> ^ 1 error generated. /usr/src/lib/libdpv/dprompt.c:40:10: fatal error: 'string_m.h' file not found #include <string_m.h> ^ 1 error generated. /usr/src/lib/libdpv/dpv.c:42:10: fatal error: 'string_m.h' file not found #include <string_m.h> ^ 1 error generated. In file included from /usr/src/lib/libdpv/status.c:36: In file included from /usr/src/lib/libdpv/dialog_util.h:34: /usr/src/lib/libdpv/dialogrc.h:34:10: fatal error: 'figpar.h' file not found #include <figpar.h> ^ 1 error generated. mkdep: compile failed *** Error code 1 Stop. make[5]: stopped in /usr/src/lib/libdpv *** Error code 1 Stop. This library and its libfigpar dependency were recently added and the missing include files are not yet in the running OS. Shouldn't this be bootstrapped with -I${.CURDIR}/../libfigpar or similar flags anyway ?
"make buildworld" should be using the headers from the source tree, not the installed one, and -I hackery isn't required in individual makefiles. Can you add some additional information: - version of the build host - version you're building (i.e., the svn rev) - contents of /etc/src.conf - exact build invocation
Created attachment 150083 [details] /etc/src.conf
Thanks for uploading your /etc/src.conf. Unfortunately, the contents of the file appear benign (with-respect to the reported issue). We'll still need the following information: - version of the build host - version you're building (i.e., the svn rev) - exact build invocation
Build host was FreeBSD 10.1-STABLE #0 r274808 (amd64) I'm not sure what the revision was when I tried this build. r275307 or a little earlier (I was able to build r275307 later after installing the missing files with a "make obj && make depend && make && make install" from their source directory but there may have been a svnlite update before that). src.conf (with relatively many features excluded) is attached. I'm not sure what you mean by "exact build invocation" ? It was "make buildworld", starting with an empty /usr/obj.
> I'm not sure what you mean by "exact build invocation" ? It was "make > buildworld", starting with an empty /usr/obj. Thanks, that's all I meant - i.e., it could be something like "make -j8 buildworld" or with other make variables set.
FWIW, I have a full typescript of the failed build (~400k compressed), but the web interface seems to time out when I try to attach it.
Without knowing precisely what revision your tree is at prior to building, it's not possible to say whether you're hitting the error that was fixed in r274203: http://svnweb.freebsd.org/base?view=revision&revision=274203 Between r274192 and r274203, you get exactly the error that you've reported in this bug. Can you try to update your tree to the latest version, clean, and start with a fresh buildworld? See if the problem still exists beyond r274203 (actually, I'd prefer it if the test was done with r274209 or higher).
Comment #7 seems to refer to svn head, but I use stable/10, where the new libraries and the fix to Makefile.inc1 were committed together at r275040. Given the above it may not be that important, but the failed build started at Sat Nov 29 15:51:21 CET 2014. Looking at the commit mails at http://lists.freebsd.org/pipermail/svn-src-stable-10/2014-November/thread.html , my tree revision then was almost certainly r275236.
D'Oh, you hadn't mentioned a branch previously (didn't know you were compiling stable/10 on your 10.1-STABLE build-box; thought you were compiling HEAD on your 10.1-STABLE build-box). That being the case... I'm not sure I have an explanation for your build failure. Largely because so many others are not having an issue. Here, have a look at our continuous integration system (Jenkins): https://jenkins.freebsd.org/view/FreeBSD_src_stable/ stable/10 is all-gravy according to Jenkins.
Currently, prevailing logic tells me it's something in your src.conf I'll try a couple builds with what you've got there -- which will take some time (doing, say, a binary-chop method if/when I can replicate the failure). It would help if you could try running a build without src.conf to see if everything comes up "gravy" for you (eliminates the build failure). This would prove (or disprove) that it's something in src.conf. If -- without src.conf -- you get a clean build, could you then try the same binary-chop method that I am planning in-effort to find the suspect culprit?
The problem is apparently with WITHOUT_CROSS_COMPILER=true in src.conf. Without this, a clang is built with -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\", world is built with it and everything goes well. With this flag set to true, a clang is built with -DDEFAULT_SYSROOT=\"\" and buildword uses it, using for instance the system includes instead of those from /usr/src, and fails when new files appear like with libdpv. I didn't investigate if this compiler is a misconfigured first stage one or already the final one, but in either case there is a problem since even if it is the second case and this is a feature, it is a much more aggressive shortcut than what src.conf man page suggests, with serious limitations like the case I met. In any case, this is unrelated to libdpv and the title of the bug report should certainly be changed. I will stop using this flag for now but don't intend to investigate the case further.
If you find the cycles, could you dup what we've found into a new bug with proper title/context (disassociating from dpv)? I'd like to close this bug but don't want to lose the value-add lurking within a potential fix to the real (underlying) problem.
As requested, I opened the more accurate bin/196193.
Supersceded by PR 196193.