Platform-defined targets, fewer hard-coded OS/arch facts: 12 engine gaps + 3 bugs measured while porting a C program (cmd) to ok images, FreeBSD and i386 with mcpp only #911

Activity

1. Sunrisepeak

   added

   enhancementNew feature or requestNew feature or request

   on Nov 8, 2026
2. Sunrisepeak

   added a commit that references this issue on Nov 9, 2026

   2026.11.9.1: targets and providers; a platform defines rows; mcpp#911…

   ...

   9edccc4
3. Sunrisepeak commented on Nov 9, 2026

   

   Sunrisepeak

   on Nov 9, 2026

   MemberAuthor

   More actions

   Re-measured on 2026.11.9.1: most of G1–G12 / B1–B3 hold; 8 follow-up observations (N1–N8)

   Thank you for #912. That was a very fast turnaround. I re-ran the whole port with the released 2026.11.9.1 (linux-x86_64 tarball, llvm 23.1.3). For openkal-run 0.5.4 I used git = "https://github.com/mcpplibs/openkal-image.git", tag = "0.5.4", since mcpplibs/mcpp-index#743 is not merged yet. Below is what I measured, followed by a few follow-up observations. The observations come with workarounds that already work today, and a possible direction for each. They are offered for consideration only. How or whether to change anything is of course your call.

   Permalinks are pinned to the v2026.11.9.1 tag commit 9edccc4.

   中文摘要

   用 2026.11.9.1 发布版把移植实验完整重跑了一遍。G1–G4、G6、G7、G11、G12 和 B1–B3 实测都已生效。cmd 现在能不改源码直接编译成 FreeBSD 原生程序。借助一个运行器脚本，mcpp run --target x86_64-freebsd 能在真实的 FreeBSD 14.5 虚拟机里执行并返回退出码。

   另外观察到 8 个后续问题（N1–N8），每个都附上了现在就能用的绕过方式和一个可供参考的思路，不要求上游按此修改：

   • N2、N3 的链接部分和 N7 似乎同源：平台定义的行已在运行时登记，但 has_own_sysroot()、freestanding::resolve() 等判断仍只查内置表。
   • N1：共用同一入口文件的两个程序会共享一个入口对象，其中一个程序的 defines 会被悄悄带进另一个。
   • 其余几项较小：N4 是误报，N5 是 git 工作区成员的补丁问题，N6 缺一条警告，N8 是打包问题。

   另外更正 #911 第 7 节的一处说法：openkal 其实有 kal_process_stop_requested()，cmd 调用一次即可挺过 Ctrl+C。那一条不是缺口。

   ---

   1. What now works (measured)

   Item	Result	How it was checked
   G1	✅	[[platform.define]] x86_64-freebsd + [[platform.provider]]. The build goes to target/x86_64-freebsd/, cfg(os = "freebsd") applies, and mcpp why platform lists the row.
   G2	✅	mcpp why flags was the tool that located N3 below. Very useful.
   G3	✅	A hosted = true provider serving x86_64-none-elf: -ffreestanding is gone.
   G4	✅	driver = "compiler" on the FreeBSD row: crt objects, libraries and PT_INTERP come from the driver. The hand-written crt list is gone.
   G5	✅ (see N2, N4)	"the artifacts are for freebsd, not this machine: their runtime closure is not checked here"
   G6	✅	No descriptor_keys. Index dependencies (openkal, openkal-run) resolve for x86_64-freebsd.
   G7	✅	openkal-run 0.5.4, unpatched, takes the graph's openkal-posix as mcpp:kernel-abi. The lock has no openkal-linux, and the runner's output is byte-identical to the official okrun.
   G8	✅ for index archives (see N5)	A patch written as a/mcpp.toml applies to openkal-run 0.5.3 from the index.
   G9	✅ for shared sources (see N1)	[targets."COMMAND.COM".build] defines compiles the 73 shared units under obj/_variant/COMMAND_COM/.
   G10	partly (see N8)	mcpp pack --target x86_64-freebsd --mode static packs.
   G11	✅	runner = ["<vm-runner>", "{}"] boots a FreeBSD 14.5 VM, runs the program and returns its status. mcpp run cmd.exe --target x86_64-freebsd -- /d /c "ver & exit /b 3" ends with 3.
   G12	✅	--target i686-none-elf builds an ELF32 i386 program that runs, with no toolchain wrapper. why flags shows row -march=i686 and row -m elf_i386.
   B1	✅	[targets."COMMAND.COM"] in the generated launcher manifest
   B2	✅	cmd.exe.oke, with the conflict reported
   B3	✅	The note names the programs not packed; --all-programs gives an okb with 2 architectures × 2 images.

   The following ran in a real FreeBSD 14.5 VM, all dynamically linked:

   • a C program;
   • a C++ program (exceptions, iostream; libc++.so.1, libcxxrt.so.1);
   • cmd itself, built unchanged for x86_64-freebsd, which passes the same batch test as the Linux build;
   • an okrun over openkal-posix built for FreeBSD, running the 9.1-built cmd.exe.oke with the same output (except hard links, which openkal does not have).

   Of the workarounds in the §6 acceptance table:

   • Removed: borrowing x86_64-none-elf, the i386 toolchain wrapper, -fhosted, the hand-written crt list, and descriptor_keys. The VM driver is still there, but it is now plugged in as a runner, so testing goes through mcpp run (G11).
   • Mostly removed: the openkal-run patch, and the archive-rooted patch paths. A FreeBSD build of openkal-run still needs a 3-line patch, but that part belongs to openkal-image.
   • Still in place: cmd's entry wrapper (N1). Forced static linking became optional, but a dynamic build meets N2/N3.

   ---

   2. Follow-up observations

   The table gives my own reading of each item. A ✓ in the last column means a workaround that does not change mcpp was verified here.

   #	Summary	My reading	Workaround
   N1	Two programs with the same main file share one entry object compiled with one program's defines	defect (silent)	✓ separate entry file per program
   N2	The hermetic check refuses a defined row's dynamic program because of its target-side loader path	defect	✓ static link, or MCPP_ALLOW_HOST_LIBS=1
   N3	The payload's libc++ headers and host -L/-rpath reach a defined row with a sysroot	partly usage, partly gap, partly defect	✓ a c++-abi layer package; static link avoids the RPATH
   N4	The interposition warning compares a FreeBSD program with host glibc	defect (warning only)	✓ ignore
   N5	patches on a git workspace member breaks the member's path edges	defect	✓ use the index archive
   N6	[platform.link] flags is silently unused with driver = "compiler"	documented; a diagnostic may help	✓ [platform.build] ldflags
   N7	A defined row's march / link-emulation are read but not applied	defect (vs SPEC-016 §2.1)	✓ state the flags in the platform's build / link.flags
   N8	Default pack runs host ldd on a foreign dynamic ELF; --mode static labels a dynamic program -static	gap + defect	✓ static link

   A possible common cause of N2, N3 (link side) and N7

   The defined row is registered at run time with all its fields (prepare/platform.cpp#L185-L215), and selection, reports and cfg all use it. However, a few predicates further down still read only the compiled-in tables:

   • Triple::has_own_sysroot() looks only at kKnownTargets and at a few OS names. It decides the loader exemption in hermetic.cppm#L246-L253 (N2), and the early return of the host C-runtime group in linkmodel.cppm#L503-L504 (probably the gcc-runtime -L/-rpath in N3).
   • freestanding::kTable / resolve() is built from builtin::kRows at compile time (N7).

   A direction you may wish to consider: let these predicates ask the resolved row and provider (a declared sysroot, execution ≠ this machine, the row's machine description) rather than the compiled-in tables. One change there might settle three observations at once. SPEC-016 already reads that way: §2.1 says the machine description is "引擎原样使用" (used by the engine as written), and §5 says "平台定义的行不取宿主载荷的 C 库" (a platform-defined row does not take the host payload's C library). I have not verified that the llvm payload's -L …/lib/x86_64-unknown-linux-gnu in N3 comes from the same place, so please treat that part as a guess.

   N1 — one entry object for two programs that share main

   [build]
   sources = ["*.c", "!cmain.c"]
   
   [targets."cmd.exe"]
   kind = "bin"
   main = "cmain.c"
   
   [targets."COMMAND.COM"]
   kind = "bin"
   main = "cmain.c"
   defines = ["ENABLE_AUTOEXEC=1"]      # same with [targets."COMMAND.COM".build] defines

   build.ninja contains one obj/cmd/cmain.o with -DENABLE_AUTOEXEC=1, linked into both bin/cmd.exe and bin/COMMAND.COM, and nothing is reported. The cause appears to be entry_object: it reuses the unit by source path, and entryFlagsApplied applies the first program's flags once. With the [targets.X.build] spelling, the 73 shared sources do get their variant, but the entry stays shared. That is why cmd still needs its mcpp/cmain_command.c wrapper.

   Possible directions: when two programs give one entry different flags, compile one entry object per program (as G9 already does for shared sources), or refuse and name both programs. Either would avoid the silent mix. Separately, docs/04-mcpp-toml.md#L544-L546 still says a shared source is never compiled two different ways, which G9 now does.

   N2 — hermetic check vs a target-side loader

   A dynamic program for the FreeBSD row (with sysroot = { path = … }) stops at:

   error: hermetic link check failed — the sandbox toolchain resolves its C runtime outside the sandbox:
            /libexec/ld-elf.so.1 (outside the sandbox)
   

   /libexec/ld-elf.so.1 is the target's PT_INTERP, the same situation that the comment above hermetic.cppm#L246 describes for Android. Today every consumer of such a platform needs MCPP_ALLOW_HOST_LIBS=1 or [build] allow_host_libs, which reads as "link host libraries" although nothing from the host is linked. Static linking avoids the check entirely (verified). Direction: see the common cause above.

   N3 — what a hosted defined row receives from the toolchain payload

   With only sysroot = { path = "sysroot", provides = ["mcpp:c-abi=freebsd-libc"] } (also tried "hosted-standard-library" and "mcpp:c++-abi=libc++"), the report shows c++-abi —, and mcpp why flags shows:

   toolchain -isystem<llvm>/include/c++/v1                  # also on C units: '__config_site' file not found
   engine    -stdlib=libc++ --rtlib=compiler-rt --unwindlib=libunwind
   toolchain -L<llvm>/lib/x86_64-unknown-linux-gnu  -Wl,-rpath,<same>
   toolchain -L<llvm>/lib                           -Wl,-rpath,<same>
   engine    -L<gcc-runtime>/lib64                  -Wl,-rpath,<same>
   

   What works today (usage): a c++-abi + compiler-runtime layer package for the system's own libc++. With it, cxxFromGraph holds and the payload's headers leave the compile (hostflags.cppm#L411-L419). It needed two details:

   • Library by file path. The package names the library by absolute file (<SR>/usr/lib/libc++.so, or libc++.a + libcxxrt.a for static), because a -lc++ resolves to the payload's Linux libc++ first: the host -L precede the package's flags.
   • Two platform packages. Static and dynamic needed one platform package each.

   The three host paths remain in the FreeBSD program's RPATH.

   Possible directions, smallest first:

   • the link side might follow the common cause above;
   • a sysroot (or a hosted provider) might be allowed to state that it holds the C++ run-time and the compiler run-time too, i.e. that it is the whole target side, as the MinGW pairing already does for its payload. That likely touches SPEC-002's c-abi exclusivity rule, so it may deserve its own discussion.

   N4 — interposition warning against host glibc

   For the FreeBSD C++ program, symbol_provision.cppm#L271 reports environ and __progname as "also provided by <glibc payload>/lib/libc.so.6". The program loads libc.so.7 from FreeBSD. Direction: skip the check where the row's execution is not this machine, or resolve DT_NEEDED inside the declared sysroot. It is only a warning, so it is low priority.

   N5 — patches on a git dependency that is a workspace member

   openkal-run = { git = "https://github.com/mcpplibs/openkal-image.git", tag = "0.5.4",
                   patches = ["patches/0001-openkal-run-freebsd-space.patch"] }   # a/mcpp.toml, from the package root

   error: path dependency 'openkal-ld' (at '<home>/cache/src/mcpplibs.openkal-run/ld') has no mcpp.toml
   

   For a member, dep_root is gitRoot / member, and graph.cpp#L1677-L1692 materializes only that directory. The member's openkal-ld = { path = "../ld" } then points outside the variant. The same patch on the index archive works, because the whole archive is copied.

   Direction: copy the clone root into the variant and keep the member's relative position. Alternatively, resolve the member's path edges against the original clone, since §"A package of a git repository" already says such an edge names the same git source at the same commit.

   N6 — [platform.link] flags with driver = "compiler"

   This is documented (specs/platforms.md#L282: only for driver = "lld"), and [platform.build] ldflags = ["-pthread"] is the right spelling. I only mention it because the value was dropped without a word. A manifest warning, in the style of the other platform-statement checks, might save the next author a link failure.

   N7 — a defined row's machine description

   [[platform.define]]
   triple         = "i386-svr4"
   clang-triple   = "i386-unknown-none-elf"
   object-format  = "elf"
   execution      = "svr4"
   march          = "i386"
   link-emulation = "elf_i386"

   mcpp why flags --target i386-svr4 shows no row layer at all (no -march=i386). With driver = "lld" the link line is -flavor gnu --compress-debug-sections=zlib with no -m elf_i386. The program still comes out as ELF32, because lld infers the emulation from the objects. The built-in i686-none-elf gets both flags. Stating them in the platform's build.cflags and link.flags works today. Direction: see the common cause above.

   N8 — packing a defined row's dynamic program

   • mcpp pack --target x86_64-freebsd (vendored): error: ldd failed on …/bin/COMMAND.COM: command exited with 127. Only an ELF without PT_INTERP and without DT_NEEDED skips ldd (pack.cppm#L3163-L3173).
   • --mode static produces cmd-0.1.0-x86_64-freebsd-static.tar.gz whose program is still dynamically linked (interpreter /libexec/ld-elf.so.1). program_row labels a defined row static without changing the link.

   Possible directions:

   • for a row whose execution is not this machine, either compute the closure from DT_NEEDED and the declared sysroot without running anything, or refuse vendored mode with a message that names --mode static / static linking;
   • for --mode static, check the produced program or refuse when the row's provider does not link statically.

   With static linking (ldflags = ["-pthread", "-static"] in the platform) the default mcpp pack already succeeds.

   ---

   3. A correction to §7 of the issue

   §7 said "openkal: no asynchronous interrupt notification; under okrun a shell cannot survive Ctrl+C". That is not right. openkal has kal_process_stop_requested() (0.11; openkal-linux takes over SIGINT/SIGTERM/SIGHUP). Calling it once at the top of cmd's main under __OPENKAL__ makes the ok image survive Ctrl+C as the native build does. So that item is a porting step in cmd, not an openkal gap. Sorry for the noise.

   Appendix — the FreeBSD row as measured (dynamic)

   # freebsd-platform/mcpp.toml   (sysroot → an extracted FreeBSD 14.5 base.txz)
   [package]
   name    = "freebsd-platform"
   version = "0.1.0"
   mcpp    = ">=2026.11.9.1"
   
   [platform]
   toolchain = "[email protected]"
   sysroot   = { path = "sysroot", provides = ["mcpp:c-abi=freebsd-libc"] }
   
   [[platform.define]]
   triple        = "x86_64-freebsd"
   clang-triple  = "x86_64-unknown-freebsd14.5"
   object-format = "elf"
   family        = "unix"
   execution     = "freebsd"
   
   [[platform.provider]]
   serves = ["x86_64-freebsd"]
   hosted = true
   
   [platform.build]
   ldflags = ["-pthread"]          # FreeBSD keeps POSIX threads in libthr
   
   [platform.link]
   driver = "compiler"
   
   [platform.layers]
   "kernel-abi"       = false
   "c-abi"            = false
   "c++-abi"          = { path = "../freebsd-cxx" }
   "compiler-runtime" = { path = "../freebsd-cxx" }

   # freebsd-cxx/mcpp.toml — the system's own libc++ (over libcxxrt) and libgcc
   [package]
   name     = "freebsd-cxx"
   version  = "0.1.0"
   provides = ["hosted-standard-library", "mcpp:c++-abi=libc++", "mcpp:compiler-runtime=libgcc"]
   
   [targets.freebsd-cxx]
   kind = "lib"
   
   [build]
   sources      = []
   include_dirs = ["../freebsd-platform/sysroot/usr/include/c++/v1"]
   # By file: a -lc++ would find the toolchain payload's Linux libc++ first (N3).
   ldflags      = ["<SR>/usr/lib/libc++.so"]     # static variant: libc++.a + libcxxrt.a

   # a project
   [target.x86_64-freebsd]
   platform = { path = "../freebsd-platform" }
   runner   = ["../vm/fbrun.sh", "{}"]            # boots the VM, runs, returns the status (G11)

   Happy to re-test any of these on a branch, or to split items into separate issues if that is easier to track.