Der gcc wird von einer vorgängerversion des gcc compiliert, dann nochmals mit sich selbst.
d.h. alles was man braucht ist ein binary vom alten gcc und den source code vom neuen.
wenn jetzt python noch dazukommt wird es eindeutig komplizierter und unsicherer. Denn zuerst muss man mit dem alten gcc python bauen, damit man dann damit und dem alten gcc den neuen gcc bauen kann. Das ist die doppelte Anzahl von möglichen Sicherheitslöchern (ähnlich diesem hier: http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a/ )
Und wahrscheinlich noch weitere Pakete. Die würde man bei einem Update auch mit installieren und neu übersetzen müssen. Und gerade bei der glibc/binutils/gcc-Toolchain macht das "richtig" Spaß.
Ob ein Distributor jetzt noch Python hinzufügt, welches er wohl ohnehin mit ausliefern wird, macht den Braten auch nicht mehr fett.
Ähnliche Effekte hast du auch mit den core-utils. Die nutzen OpenSSL wenn vorhanden. Aber versuch mal OpenSSL zu übersetzen, wenn du keine core-utils hast.
Ist auch etwas merkwürdig. Das Buildsystem von Android besteht aus Grail für Java Apps, Shell Skripten die Python Skripte nutzen um schließlich ein gewaltiges Makefile zu erbauen und starten. Keine Ahnung was da Frontend Python sein soll.
Denn dann ergibt sich ein Henne-Ei Problem, da ja Python selbst wieder in C geschrieben ist.
Und warum ist dir dieses Henne-Ei-Problem nicht schon beim C-Compiler aufgefallen, der in C geschrieben ist?
Der gcc wird von einer vorgängerversion des gcc compiliert, dann nochmals mit sich selbst.
d.h. alles was man braucht ist ein binary vom alten gcc und den source code vom neuen.
wenn jetzt python noch dazukommt wird es eindeutig komplizierter und unsicherer. Denn zuerst muss man mit dem alten gcc python bauen, damit man dann damit und dem alten gcc den neuen gcc bauen kann.
Das ist die doppelte Anzahl von möglichen Sicherheitslöchern (ähnlich diesem hier: http://scienceblogs.com/goodmath/2007/04/15/strange-loops-dennis-ritchie-a/ )
Ich bin jetzt auch kein Fan von noch mehr Software, die an der GCC hängt, aber betrachten wir doch mal die aktuellen (optionalen) Abhängigkeiten:
- glibc (oder beliebige C-Bibliothek)
- binutils
- gmp
- mpfr
- mpc
Und wahrscheinlich noch weitere Pakete. Die würde man bei einem Update auch mit installieren und neu übersetzen müssen. Und gerade bei der glibc/binutils/gcc-Toolchain macht das "richtig" Spaß.
Ob ein Distributor jetzt noch Python hinzufügt, welches er wohl ohnehin mit ausliefern wird, macht den Braten auch nicht mehr fett.
Ähnliche Effekte hast du auch mit den core-utils. Die nutzen OpenSSL wenn vorhanden. Aber versuch mal OpenSSL zu übersetzen, wenn du keine core-utils hast.
Außerdem gäbe es ja noch PyPy - da tritt das Problem nicht auf
Wäre es nicht sinnvoll wenn auch noch weitere Compiler-Anbieter (wie z.B. der ICC) sich beteiligen würden?
"Denkbar wäre sogar, das Frontend in Python zu schreiben, und dem erfolgreichen Beispiel des Android-Build-Systems zu folgen."
Der Original-Text liest sich in Bezug auf Android-Build da etwas anders.
Gruss,
Kay
Ist auch etwas merkwürdig. Das Buildsystem von Android besteht aus Grail für Java Apps, Shell Skripten die Python Skripte nutzen um schließlich ein gewaltiges Makefile zu erbauen und starten. Keine Ahnung was da Frontend Python sein soll.