If tinycc is linked with a musl which in turn was built by tcc-mes,
then this musl has broken implementations of the math library on
certain arches, which is in turn caused tcc-mes having stubbed math
functions. The only way to get a trustworthy musl is to build it with
an intermediate tcc-musl, where the intermediate tcc-musl has at least
working ldexp and frexp.
Issues in the math library were surfacing on RISC-V when building gmp.
The base version of TinyCC does not correctly support complex array
types in function parameters. A patch was applied to add this support,
but the old version of this patch broke VLA code generation, which in
turn caused execvp() in musl to be miscompiled. Here, I have replaced
this patch with a sound version.
this to a valid value otherwise __TINYC__ ends up being misdefined, and
some things in the build depend on this.
Ironically, we have another build problem in libc.c which was hidden
by the incorrect __TINYC__ value - for the moment, bodge this in sources.nix..
this way, you can run `nix flake check --all-systems` after making a change to ensure the entire foundation still builds
Reviewed-on: #21
Reviewed-by: Jake Hamilton <jake.hamilton@hey.com>
Co-authored-by: Piper McCorkle <contact@piperswe.me>
Co-committed-by: Piper McCorkle <contact@piperswe.me>
Use case: downstream users may want to override the GNU mirror URL,
as the main ftp.gnu.org repository has caused slow downloads. Now it is possible to
perform e.g.
```nix
((import ./default.nix).extend {
modules = [{ config.aux.mirrors.gnu = "https://www.nic.funet.fi/pub/gnu/ftp.gnu.org/pub/gnu/"; }];
}).config.exports.resolved.packages
```
Reviewed-on: #14
Reviewed-by: Jake Hamilton <jake.hamilton@hey.com>
Co-authored-by: Aleksi Hannula <ahannula4+auxolotl@gmail.com>
Co-committed-by: Aleksi Hannula <ahannula4+auxolotl@gmail.com>
To test: `nix build .#packages.i686-linux.stage1-python && nix build --rebuild --keep-failed .#packages.i686-linux.stage1-python`.
Python does print its build date on startup, which means this is a bit confusing, but eh
```
# ./result/bin/python3
Python 3.12.0 (main, Jan 1 1970, 00:00:00) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
```
Reviewed-on: #17
Reviewed-by: vlinkz <vlinkz@snowflakeos.org>
Co-authored-by: 5225225 <5225225@mailbox.org>
Co-committed-by: 5225225 <5225225@mailbox.org>
https://ftp.gnu.org is very, *very* slow. From the [GNU downloads page](https://www.gnu.org/prep/ftp.en.html):
> [...]please try to use one of the many mirrors of our site listed below: the mirrors will give you faster response. [...] You can use the generic URLs https://ftpmirror.gnu.org and http://ftpmirror.gnu.org to automatically choose a nearby and up-to-date mirror.
Indeed, in my experience the mirrors are much faster. I don't see a reason we shouldn't default to them personally, so I've changed the default here.
Also see: auxolotl/labs#26
Reviewed-on: #8
Co-authored-by: Ruby Iris Juric <ruby@srxl.me>
Co-committed-by: Ruby Iris Juric <ruby@srxl.me>
Right now when running the `stage1-python` binary and attempting to import zlib module, you get
```
>>> import zlib
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: Error loading shared library libz.so.1: No such file or directory (needed by .../lib/python3.12/lib-dynload/zlib.cpython-312-i386-linux-gnu.so)
```
By linking with rpath instead, the resulting binary knows the exact path to look for zlib
Reviewed-on: #6
Co-authored-by: Victor Fuentes <vlinkz@snowflakeos.org>
Co-committed-by: Victor Fuentes <vlinkz@snowflakeos.org>
When trying to build stage1-bash under a 32bit kernel, the configure script crashes because of a segmentation fault during the test for sigsetjmp/siglongjmp.
This can be fixed by bypassing the test and always assuming that the functions are not available. This does not have a negative impact on any downstream packages and makes the bootstrap chain complete.
From what I could find out, this seems to be a problem that only occurs when trying to build bash on a 32bit kernel using tcc. I can also get the build to work without the patch by either running it under a 64bit kernel, or by using the gcc from my host instead of the bootstrapped tcc.
Reviewed-on: #3
Reviewed-by: vlinkz <vlinkz@snowflakeos.org>
Co-authored-by: nzbr <mail@nzbr.de>
Co-committed-by: nzbr <mail@nzbr.de>
I can't see any reason not to do this and it makes building with e.g. hydra easier. AFAICS forgejo doesn't support anonymous/public git+ssh access?
Reviewed-on: #5
Reviewed-by: Jake Hamilton <jake.hamilton@hey.com>
Co-authored-by: srd424 <srd424@noreply.git.auxolotl.org>
Co-committed-by: srd424 <srd424@noreply.git.auxolotl.org>
I'm pretty sure this is the minimal set of files to make things work, but feel free to experiment.
We still need to figure out why I'm the only one this failed for, and write some tests. I suspect it may be that I had to run as root, due to lix not allowing the `--system` argument when run by an ordinary user. I don't think we, uh, have a test framework yet, so I'm leaving that for another CL...
