[Bug 240506] picobsd build script not producing usable output

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Sep 12 02:33:39 UTC 2019


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240506

Kyle Evans <kevans at freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugs at FreeBSD.org,
                   |                            |re at FreeBSD.org

--- Comment #2 from Kyle Evans <kevans at freebsd.org> ---
CC'ing re@, because I think this is technically their territory being in
release/, and CC'ing bugs@ to keep it on a list. 

Here's a summary of the bugs I've encountered in picobsd so far, and I still
haven't gotten anything usable:

- Script unconditionally sets WITHOUT_CLANG/WITHOUT_CLANG_BOOTSTRAP [0] without
dealing with GCC_BOOTSTRAP. The libllvm build fails because WITHOUT_CLANG shuts
off all of the LLVM_TARGET_* -- build failure.

- Fixing that, native builds cannot work. The script does `set -e`, then [1] --
on a native build, ${o_arch} == `uname -m` and we don't descend down && path,
leaving the function with an erroneous exit code and the script bails out.

- Fixing that, native amd64 builds cannot work. None of these [2] are valid CPU
types for amd64 -- only i386. One can supply their own kernconf, so let's
ignore this for now. 

What does work?

- Cross-builds -- kind of, for very primitive cases. [3] sets TARGET_ARCH and
ARCH to whatever was passed in via --arch. This assumes ARCH=TARGET_ARCH, which
rules out, e.g., arm.armv7, most mips flavors, most powerpc flavors, riscv,
arm64

- The i386 build probably does, but I had to fix the ${CONF}/${CONFFILE} target
in Makefile.conf to wrap [ -f ... ] && cpp in () || true in order to
continue... around here I ran out of patience to tolerate further failures for
the night, so I left the build running and detached for the night.

I think re@ should consider dropping this before 13.0, because:

1.) It has no active maintainer and has a lot of deferred maintenance that
needs handled (see: pretty broken by default, and it's been this way for a
while),

2.) It can't handle cross-builds,

3.) I think it fills a niche that's better fit for nanobsd or mfsbsd, which see
more active maintenance

[0]
https://svnweb.freebsd.org/base/head/release/picobsd/build/picobsd?view=markup&pathrev=349453#l975

[1]
https://svnweb.freebsd.org/base/head/release/picobsd/build/picobsd?view=markup&pathrev=349453#l186

[2]
https://svnweb.freebsd.org/base/head/release/picobsd/qemu/PICOBSD?revision=349253&view=markup&pathrev=349453#l17

[3]
https://svnweb.freebsd.org/base/head/release/picobsd/build/picobsd?view=markup&pathrev=349453#l972

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the freebsd-bugs mailing list