Post by Michael KraemerPost by Michael BaeuerleWas zum Beispiel auch nicht geht ist einfach einen aktuellen GCC zu
compilieren. Der binaere 2.95 kann weder einen 3.4 noch einen 4.x
Compiler bauen. Einen 3.3er habe ich zu Stande bekommen, aber auch da
nur mit manuellem Eingriff. Einfach nur mit "make" erzeugt er
Assemblercode den meine CPU nicht ausfuehren kann. Dieser 3.3er konnte
dann ebenfalls keinen 3.4er bauen.
http://www.gsi.de/~kraemer/COLLECTION/AIX/aixpdslib.seas.ucla.edu/packages/gcc.html
Aha, den Assembler Fix habe ich schonmal nicht. Und da steht in dem Link
auch nochmal, man soll die ksh wegwerfen wenn man den Build noch erleben
will.
Post by Michael Kraemervielleicht nimmst Du wirklich erstmal einen vorkompilierten gcc
und versuchst was einfacheres zu kompilieren.
Dann weisst Du wenigstens ob gcc und ld miteinander koennen.
(ich sehe eben keinen Grund warum nicht).
Ich habe gerade nochmal nachgeschaut, also binaer hatte ich schon
probiert 2.95.3 (zu alt) und 3.4.3 (g++ fehlt). 3.3.6 aus pkgsrc (C++
funktioniert nicht wirklich), vielleicht wegen den Bugs im Assembler.
Post by Michael KraemerPost by Michael Baeuerle[...]
Nein, die ksh ist bei manchen Sachen wirklich elend langsam. Ist mir bei
einem von meinen Skripten auf einer x86-Maschine auch schon aufgefallen
als ich es mit allen Shells durchgetestet habe (dort pdksh vs bash).
Ein intelligent gestricktes script laeuft auf allen shells so,
dass man nicht zu lange wartet ...
Hoere ich da unterschwellig heraus, dass du meinem Script einen geringen
IQ unterstellst ;-)
Bei meinem Script wird massenweise Zeug aufgerufen (awk, sed, etc.),
vielleicht liegt es daran. Wenn man das auf der 150MHz Maschine laufen
laesst ist der Unterschied zwischen bash und ksh jedenfalls auch nicht
zu uebersehen.
Post by Michael KraemerPost by Michael Baeuerle[...]
Der 2.95 den ich verwendet habe war ja ein Binaerpaket, mit irgendwas
muss man sich ja aus dem Sumpf ziehen.
Dann probier doch mit dem mal was einfaches oder
mittelschweres damit zu kompilieren.
Da funktioniert durchaus auch dickeres Zeug: fvwm oder auch ImageMagick
machen z.B. keine Probleme. Das liess sich aber halt auch mit 2.95
compilieren.
Post by Michael KraemerPost by Michael BaeuerleLeider kann man heute vieles
nichtmal mehr mit GCC 3.3 compilieren. Das meiste geht immerhin noch mit
3.4.
Sachen die gestern noch gingen, gehen heute nicht mehr.
Ja. Und wenn man dann schaut warum, liegt es an Sachen wie Variadic
macros in den Debug messages die man normal gar nicht braucht.
Post by Michael KraemerDu moegest auch bedenken, dass AIX 4.3.3 immerhin ca 10 Jahre
auf dem Buckel hat. Ich weiss nicht wieviel Zeux von heute
man noch auf einem 10 Jahre alten Linux gebacken bekommt.
Sehr viel mehr, ich betreibe auch ein Linux 2.2.26 mit einer libc von
IIRC 1999. Das ist im Vergleich der Himmel (wenn AIX die Hoelle ist),
und da muss man alles selber bauen - da gibt es binaer heute quasi
nichts mehr dafuer womit man noch was anfangen koennte.
Diese Linux-Maschine performt mit ihren zwei 180MHz PentiumPro CPUs
nebenbei die 42T in Grund und Boden, da macht das Compilieren richtig
Spass im Vergleich. Selbst wenn man nur eine CPU benutzt sieht die 42T
dagegen noch kein Land.
Post by Michael KraemerPost by Michael BaeuerleDort liegt aber auch ein binaerer GCC 3.4.3, den werde ich auch noch
testen.
Gerade mal das Archiv inspiziert: Da ist gar kein g++ drin, also genau
wie bei dem den ich hier schon hatte.
Post by Michael Kraemerftp://ftp.thewrittenword.com/packages/by-architecture/powerpc-ibm-aix4.3.3.0/
Interessant. Muss ich mir morgen in der 4ma mal runterladen und schauen
ob da ein g++ drin ist, hier ueber ISDN betraegt die prognostizierte
Download-Zeit ca. 15h ...
Post by Michael KraemerPost by Michael Baeuerle[...]
Jein, bei AIX ist schon auch vieles kaputt. Deklarationen liegen in den
falschen Header-Files (nicht POSIX konform),
zB?
Ich fand da bis jetzt nix auszusetzen.
War IIRC ein Problem mit string.h und strings.h, das benoetigte Zeug war
im falschen File deklariert. Einfach das andere zusaetzlich includen und
das Problem war geloest. Und ja, es war wirklich der Header falsch und
nicht das #include.
Post by Michael KraemerPost by Michael Baeuerlekaputte C9X Macros, da gibt
es sicher noch mehr. Ich habe auch schon Reports fuer OSS geschrieben
wenn dem so sein sollte, vielleicht sollte man das mal IBM sagen.
Haben sie bestimmt laengst repariert, und AIX 4 patcht wohl keiner mehr.
Viele configure Scripte haben deswegen auch extra Checks drin ("Checking
for AIX ...", "Checking for broken AIX ..."), da ist wohl einiges nicht
wie es sein sollte.
Und wie das bestellte Beispiel gerade eben frisch auf die Schnauze
geflogen (GCC 3.3.6):
----------------------------------------------------------------------
In file included from /usr/include/sys/pri.h:29,
from /usr/include/sys/sched.h:38,
from /usr/include/sched.h:52,
from /usr/include/pthread.h:47,
from dns.c:16:
/usr/include/sys/proc.h:203: error: parse error before "crid_t"
/usr/include/sys/proc.h:212: error: parse error before "p_class"
/usr/include/sys/proc.h:349: error: parse error before '}' token
make[3]: *** [dns.o] Error 1
----------------------------------------------------------------------
Keine Ahnung was da jetzt wieder in proc.h kaputt ist, das finde ich
auch heute nicht mehr raus, <gaehn> dafuer bin ich zu muede </gaehn>.
Post by Michael KraemerPost by Michael Baeuerledamit die da Workarounds einbauen koennen (die haben meistens selber
keinen Zugang zu AIX Maschinen). Eigentlich lag es aber gar nicht an
ihrer Software, da jetzt die Schuld komplett der OSS zuzuschieben finde
ich nicht fair.
Es ist halt unter HP-UX et al dasselbe Bild, nur an anderen Stellen.
zB musste ich immer mal "rm -f" durch ein "rm -rf" ersetzen,
weil sonst irgendein obskurer sizeof() Test in die Hose geht.
Offensichtlich, gell?
?
Micha
--
http://micha.freeshell.org/