On Wed, 29 Apr 2026 10:43:23 -0000 (UTC) Stuart Henderson <[email protected]> wrote:
> On 2026-04-29, vl <[email protected]> wrote: > > New here, maybe this is a rookie mistake, so misc it is. > > > > I wanted to cross-compile (to a different OS and arch) > > a certain nontrivial program using ports llvm. > > During make it complained that stddef.h is missing. > > > > Investigations led me to two discoveries: > > > > 1. The following headers are missing man pages: > > > > float.h > > inttypes.h > > iso646.h > > limits.h > > stdarg.h > > stdbool.h > > stddef.h > > sdtint.h > > varargs.h > > > > (For our homegrown versions in /usr/include). > > I guess this is a bug? > > Ports man-pages-posix documents most of these. > > Our versions differ. > > And varargs is a gnu extension. > > We don't have manpages for headers. > > Functions are documented, e.g. varargs -> va_start(3) > > > 2. They are commented out in ports llvm PLIST. > > I guess because they conflict with our homegrowns? > > Various ports compilers have them: > > > > *-gcc-* cross architectures. > > Smaller compilers like tcc and sdcc. > > Most notably zig, being based off llvm-20. > > Those others are not used in places where a conflict would be a > problem. The ports llvm compilers are used to compile software which > needs to coexist with base. > > > What would be the correct way to bring them back? > > A separate package similar to libcxx? > > Or a change in clang built-in includes is neccessary? > > Or there is some other reasoning behind this? > > Don't know about this. Cross compile isn't a particularly high > priority here, though.. > Thanks! I guess there is not much need to document headers if you read them. Oh well, I knew that I must have missed something, being a newbie. On crosscompiling: I know, self-hosting arches and all. Might still be useful for some emulators/, vmm experiments, docker. It is a blocker for this particular port I try my hands at. Currently I use headers extracted from llvm tarball, not ideal.
