IRC channel logs

<lrvick>When building LLVM from live bootstrap toolchain it always dies near 100% with: /llvm-project-20.1.0.src/compiler-rt/lib/builtins/emutls.c:291:3: error: 'ct_assert_0' declared as an array with a negative size

<lrvick> https://codeberg.org/stagex/stagex/src/branch/lance/llvm-bootstrap/packages/bootstrap/stage2/Containerfile#L58-L75 is how we are building.

<stikonas>lrvick: GCC directly from live-bootstrap?

<stikonas>i.e. that version 13

<lrvick>Yeah

<lrvick>x86 gcc13

<lrvick>Also tried compiling a gcc13 cross compiler to try to build llvm for x86_64 host, but same error

<lrvick>does not like the build toolchain

<stikonas>hmm, no ideas so far...

<lrvick>its a strange error and it happens when the build is at like 99.99% so a frustrating location to debug

<stikonas>I guess it's COMPILE_TIME_ASSERT(sizeof(uintptr_t) == sizeof(gcc_pointer));

<lrvick>It is the last thing in my way to bootstrap llvm/clang directly from live bootstrap so we have native cross compiler to every other arch.

<lrvick>posted in llvm room but crickets.

<stikonas>I'm not familiar enough with either project though...

<stikonas>both should be pointer size, shouldn't they?

<stikonas>i.e. 32-bits on x86

<stikonas>and RHS is typedef void *gcc_pointer;

<stikonas>so just void pointer....

<stikonas>and musl defines

<stikonas>typedef unsigned _Addr uintptr_t;

<stikonas>#define _Addr int

<stikonas>so it seems uintptr_t is unsigned int

<stikonas>should be still 32-bits on gcc

<lrvick>So that does not jump out to you as an acutal problem

<lrvick>hrm

<agg1>begun writing a little documentation, to summarize the current progress and status of a complete TinyCC driven system

<agg1>which relies upon bootstrappable, hence references are given rather often

<agg1> http://tinyfront.mooo.com/docs.html

<lrvick>Tracking llvm/i386 bug here: https://github.com/llvm/llvm-project/issues/141852

<mihi>lrvick, not sure if helpful, but if I recall correctly there used to be CMake options to build clang against musl libc (LIBCPP_HAS_MUSL_LIBC and LIBCXX_HAS_MUSL_LIBC) - not sure whether they are still relevant today

<mihi>may help to check how Alpine builds llvm (if they do)

<mihi>assuming you are building against the musl libc and have not built another libc in your environment before.

IRC channel logs

2025-05-28.log