Bug 195503 - libdpv doesn't compile
Summary: libdpv doesn't compile
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 10.1-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: Devin Teske
Depends on:
Reported: 2014-11-29 16:23 UTC by Philippe Michel
Modified: 2015-07-07 16:20 UTC (History)
1 user (show)

See Also:

/etc/src.conf (685 bytes, text/plain)
2014-12-01 22:07 UTC, Philippe Michel
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Michel 2014-11-29 16:23:38 UTC
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

make[5]: stopped in /usr/src/lib/libdpv
*** Error code 1


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 ?
Comment 1 Ed Maste freebsd_committer 2014-12-01 21:10:29 UTC
"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
Comment 2 Philippe Michel 2014-12-01 22:07:33 UTC
Created attachment 150083 [details]
Comment 3 Devin Teske freebsd_committer 2014-12-01 22:11:40 UTC
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
Comment 4 Philippe Michel 2014-12-01 22:19:46 UTC
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.
Comment 5 Ed Maste freebsd_committer 2014-12-01 22:21:39 UTC
> 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.
Comment 6 Philippe Michel 2014-12-01 22:29:24 UTC
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.
Comment 7 Devin Teske freebsd_committer 2014-12-01 22:40:33 UTC
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:


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 8 Philippe Michel 2014-12-02 21:46:17 UTC
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.
Comment 9 Devin Teske freebsd_committer 2014-12-04 01:27:28 UTC
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):


stable/10 is all-gravy according to Jenkins.
Comment 10 Devin Teske freebsd_committer 2014-12-04 01:53:47 UTC
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?
Comment 11 Philippe Michel 2014-12-07 21:47:08 UTC
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.
Comment 12 Devin Teske freebsd_committer 2014-12-18 03:49:26 UTC
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.
Comment 13 Philippe Michel 2014-12-22 15:05:28 UTC
As requested, I opened the more accurate bin/196193.
Comment 14 Glen Barber freebsd_committer 2015-07-07 16:20:53 UTC
Supersceded by PR 196193.