Bug 243727 - building 12.1-RELEASE-p2 world fails because of dependency to non-existing file libcasper.h
Summary: building 12.1-RELEASE-p2 world fails because of dependency to non-existing fi...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.1-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2020-01-30 12:24 UTC by olaf
Modified: 2020-02-05 20:40 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description olaf 2020-01-30 12:24:14 UTC
Building world fails:

In file included from /usr/src/bin/dd/dd.c:60:
/usr/include/capsicum_helpers.h:42:10: fatal error: 'libcasper.h' file not found
#include <libcasper.h>
1 error generated.
*** Error code 1

make[4]: stopped in /usr/src/bin/dd
*** Error code 1

make[3]: stopped in /usr/src/bin
*** Error code 1

make[2]: stopped in /usr/src
*** Error code 1

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

make: stopped in /usr/src

I think the bug is that the variable 
in /etc/src.conf has no effect here.
Comment 1 Mark Johnston freebsd_committer 2020-02-05 00:52:50 UTC
We should install libcasper.h regardless of whether WITHOUT_CASPER is set.  This is because libcasper.h also defines stubs of its routines for this case.  Does the build succeed if you remove the WITHOUT_CASPER setting?
Comment 2 olaf 2020-02-05 11:22:39 UTC
I think it would be better if 'make delete-old' would not delete any header files in /usr/include.

Right now, 'make buildworld' fails again. Of course it does, libcasper.h does no longer exist.
Comment 3 Mark Johnston freebsd_committer 2020-02-05 15:02:51 UTC
(In reply to olaf from comment #2)
I guess this is the same issue as PR 242971, which was recently fixed.
Comment 4 oz42 2020-02-05 19:23:13 UTC
(In reply to Mark Johnston from comment #3)
Nope, this is opposite to my proposal: let us 'make delete-old' keep /usr/include as is so that future security (!) bugs can be fixed by guys like me who run their self compiled, customized world and kernel.

Right now, 'make buildworld' failure means: nobody can patch security patches, as a result: a forever vulnerable FreeBSD system. I assume that we all do not want that.
Comment 5 oz42 2020-02-05 19:24:08 UTC
See also PR 242217
Comment 6 oz42 2020-02-05 19:43:18 UTC
Just one more note: I would love to have my 'main' system with SMTP, IMAP, WWW, authoritative DNS and such on a FreeBSD box. I have the knowledge. But for the migration two months ago I decided to move all stuff to Linux. Again. Because from a server admin's view, Debian Linux seems to be more mature in terms of bugs that are obvious. It just works as expected.

I still consider FreeBSD as 'great idea, but not yet production ready' because one of the best feature compared to Linux (customized world and kernel, all built according to the FreeBSD handbook of course) is severely broken to me.

Right now, my productive slave DNS is on FreeBSD, but not more. If somebody hacks it because patching security issues is impossible to me, then I'll replace it with a Linux box.

It would be great if somebody 'in charge' would read this, but I do not expect that. In fact, my bug reports on Debian or LineageOS are handled within a reasonable time frame, here they are not. And Debian and LineageOS is volunteer's work just like FreeBSD is.

I feel a bit being ignored with all the bugs that I have reported.

Sorry folks. This is no rant. FreeBSD is technically speaking the best server OS in town. But I get the feeling that noone wants to change a thing when it's about self built world and kernel which is the greatest feature - a tailor made OS just for my needs.

Anyway, keep up the good work!
Comment 7 Mark Johnston freebsd_committer 2020-02-05 20:40:06 UTC
(In reply to oz42 from comment #4)
I understand the proposal.  It will cause stale headers to be left behind, which can cause problems of its own.  The libcasper issue is simply a bug and should be fixed.  We should be copying libcasper.h to the buildworld tmp dir for use during the rest of the build, regardless of whether WITHOUT_CASPER= is set, not relying on its presence in /usr/include/libcasper.h.  I verified that this happens at least on head.

Some of the other build failures you reported point to some larger underlying issue.  fsck_ffs failed to build because of a inodirty() prototype mismatch, but inodirty() is declared in the fsck_ffs header, not in any system headers.  So clearly there is a problem here that has nothing to do with delete-old.