Repository navigation
lib: Compile Mes libc against a compiler's own stddef.h and stdarg.h - #8
Merged
Merged
Conversation
The type of a wide character literal is the compiler's to decide for its target, and it names that type __WCHAR_TYPE__; a TinyCC that writes PE names unsigned short, Windows' width. Mes defined wchar_t as int whatever the compiler, so such a TinyCC compiling Mes libc against its own stddef.h, whose wchar_t is __WCHAR_TYPE__, stopped at the second definition with "incompatible redefinition of 'wchar_t'". MesCC names no __WCHAR_TYPE__ and keeps int. * include/sys/types.h (wchar_t): Define as __WCHAR_TYPE__ where the compiler names one.
include/stdarg.h defines va_arg8, which these read the argument of %e, %f and %g with, and, but for RISC-V and a system C library, a va_arg that reads every argument as a long. A compiler's own stdarg.h, which a C library may be compiled against in its place, defines va_arg alone, and its va_arg reads a double as one: TinyCC's for i386 steps over the double's eight bytes. So a TinyCC compiling Mes libc with its own include directory first, as nixpkgs' tinycc-boot-mes does, stopped at va_arg8. Where va_arg8 is undefined these now read a double with va_arg; with include/stdarg.h nothing changes. nixpkgs replaces va_arg8 with va_arg instead, which with include/stdarg.h reads a double as a long. * lib/stdio/vfprintf.c (va_arg8): Define as va_arg where stdarg.h does not define it. * lib/stdio/vsnprintf.c (va_arg8): Likewise.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TinyCC's first round in nova-nix compiles Mes libc with
TCC_TARGET_PEand TinyCC's own include directory before Mes's, as nixpkgs'tinycc-boot-mesorders them. Two assumptions in Mes's headers stopped it:include/sys/types.hdefinedwchar_tasintwhatever the compiler. A PE tcc'sstddef.hdefines it as__WCHAR_TYPE__,unsigned short, and tcc refuses the second definition.wchar_tis now__WCHAR_TYPE__where the compiler names one; MesCC names none and keepsint.vfprintf.candvsnprintf.cread%e,%fand%gwithva_arg8, which onlyinclude/stdarg.hdefines. Where it is undefined they now useva_arg, which a compiler's ownstdarg.hdefines to read a double. Withinclude/stdarg.hnothing changes, so MesCC keepsva_arg8, for the reason 481d302 gives against nixpkgs' plain replacement.A tcc built from janneke's ea3900f with
tinycc-boot-mes's defines, as a cross compiler, compiles thex86.windows.gcclibc, crt1.c, libtcc1.c and getopt.c and links a hello against them with this change. Before it, libc stops atwchar_t, then atva_arg8.Not covered: the MesCC-built libraries and the MesCC-built tcc on Windows, which nova-nix's TinyCC job builds once it pins this.
Refs Novavero-AI/nova-nix#389.