/c/ – Pufferüberlauf

wird Unternährung heilen

Dieser Kanal hatte bislang keine wirklichen Probleme mit dietlibc. Einzig zu erwähnen wäre vielleicht, dass die malloc-Implementierung für Größen >4K nicht gerade schnell ist, weil sie direkt mmap() aufruft. Hat dafür aber den Vorteil, dass deutlich weniger Speicherbloat anfällt als bei glibc. Ach, und Posix-Threads haben irgendwie einen ziemlich kleinen Stack, deutlich kleiner als der des Hauptthreads, warum auch immer.

Zu embutils liegen keine Erfahrungen vor.

ist dietlibc mit dietlibc baubar?

>>46880
In dem Sinne, dass man unter Zuhilfenahme eines existierenden C-Compilers und dietlibc einen C-Compiler kompilieren kann, fallen zumindest GCC und LLVM aus der Betrachtung, da diese in C++ geschrieben sind und dietlibc nach eigener Auskunft des Entwicklers noch nicht die nötigen Bestandteile enthält, um auf dessen Basis das Bindeglied zu einer C++-Standardbibliothek zu kompilieren.
Interessant wären aber Tiny C Compiler und lcc.

>>46907
Altes GCC (4.9.4 müsste letztes ohne C++-Dep sein) könnte auch funktionieren, wird Felix vielleicht mal probieren.

>>46907
nein, so tief absteigend meinte ich das nicht. Ich hab probiert dietlibc mit dietlibc direkt mit gcc zu bauen, also irgendwas im Sinne CC="diet gcc" make oder mit Änderungen im Makefile.add. Aber ich bin mangels armselliger Baumeisterkenntnissen komplett gescheitert.

>>46930
Die dietlibc kommt mit einem Tool namens diet, das man einfach dem gcc-Befehl voranstellt (wie du ja offensichtlich schon festgestellt hast), um gegen dietlibc statt der normalen libc zu linken. Anscheinend hast du das ja schon selbst herausgefunden. Wie das genau intern funktioniert, weiß ich auf die Schnelle nicht, aber es wird wohl irgendwelche Umgebungsvariablen und Flags setzen.

Die dietlibc selbst mit dem diet gcc zu kompilieren, ergibt aber keinen Sinn, weil die libc ja nicht gegen sich selbst linken kann. Die libc braucht gar keine libc, sie ist ja die libc.

>>46935
Aber dietlibc baut ja gegen irgendeine libc, das ist doch kein assembler Code, sondern c, mit den allen #include<...>, die da drin vorkommen.

>>46939
Alle inkludierten Dateien stammen aus dietlibc selbst.

Aus dem Makefile:


Mit -nostdinc werden die Die Standard-Include-Pfade unterbunden.

>>46954
nice. aber woher weißt dann gcc, wo er die header für <...> holen soll, wenn Standard-Include-Pfad leer ist?

>>46970
INC=-I. -isystem include dürfte dafür verantwortlich sein.

>>46979
danke! ich bin immer noch innerlich schockiert, dass ich hier immer noch nicht beschimpft worden bin, sondern sachliche Antworten bekam.

>>46935
>aber es wird wohl irgendwelche Umgebungsvariablen und Flags setzen
Es bastelt sich eine Befehlszeile, die das Compiler-Frontend ganz ähnlich mit -nostdlib (um das Linken mit der standardmäßigen C-Library zu vermeiden) und -isystem sowie ein paar plattformspezifischen Parametern aufruft. Weil das Buildsystem dasselbe versucht, tritt sich das vermutlich gegenseitig auf die Füße.
musl erspart sich im Vergleich an der Stelle ein paar Probleme unter Zuhilfenahme einer Spezifikationsdatei; der Wrapper musl-gcc ist essentiell nur ein Shellskript der Form "exec gcc -spec ... $@", während musl-clang ebenfalls Parameter verbasteln muss.
https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html

Stoss.

Ihr macht Diät, ich laufe mit meiner Musl-Bande um den Block.