amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Open Source Programme übersetzen [ - Search - New posts - Register - Login - ]

-1- [ - Post reply - ]

2006-04-30, 13:45 h

DariusBrewka
Posts: 899
[Banned user] 		Hallo ich habe mich noch nicht so mit den ganzen autoconf usw. Zeug beschäftigt, wollte aber probieren einigen Linux Tools zu compilieren, dabei habe ich Probleme die ich nicht so ganz nachvollziehen kann.

Ich habe unter Linux einen AROS Compiler installiert, d.h. er läuft unter Linux und erzeugt AROS code.

Lt. doku zu configure muss ich configure mit ./configure --host=i686-aros aufrufen, er fängt auch an zu übersetzen, nur Leider kommen dann irgendwann Fehlermeldungen, dass er irgendwelchen Test-Programme nicht starten kann, mir erscheint es auch Logisch, denn AROS Code kann Linux nicht nutzen. Eigentlich muß er die TestProgramme doch mit dem Linux Compiler compilieren oder?

Er testet z.B. auf size of int und findet richtig heraus, dass es 4 ist, aber dann kommt als nächste Zeile

code:
checking for growing stack pointer... configure: error: cannot run test programm while cross compiling

Die ganzen Configure skripte sind für jemand nicht so leicht zu verstehen dass ich daraus nicht schlau werde was gemacht wird.

[ - Answer - Quote - Direct link - ]
2006-04-30, 15:54 h

Holger
Posts: 8116
User
Zitat:
Original von DariusBrewka:
Lt. doku zu configure muss ich configure mit ./configure --host=i686-aros aufrufen, er fängt auch an zu übersetzen, nur Leider kommen dann irgendwann Fehlermeldungen, dass er irgendwelchen Test-Programme nicht starten kann, mir erscheint es auch Logisch, denn AROS Code kann Linux nicht nutzen. Eigentlich muß er die TestProgramme doch mit dem Linux Compiler compilieren oder?
Was soll das bringen? Die Testprogramme sollen die Zielumgebung testen und nicht die Compilerumgebung. Da hast Du mit nem cross-compiler wenig Chancen.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2006-04-30, 16:13 h

Holger
Posts: 8116
User
Zitat:
Original von DariusBrewka:

checking for growing stack pointer... configure: error: cannot run test programm while cross compiling
Dieses Programm soll offensichtlich überprüfen, ob ein Überschreiten der Stack-Grenze zu einem Abbruch führt, oder der Stack transparent erhöht wird.
Wäre doch ziemlich schlecht, wenn man das unter Linux ausführt und aus diesem Ergebnis dann auf Aros schließt, oder? ;)

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2006-04-30, 16:24 h

DariusBrewka
Posts: 899
[Banned user] 		Ich weiß jetzt nicht wo das Problem sein soll, aber warum soll man unter Linux mit einem Linux Compiler nicht herausfinden könne, ob AROS nun Beispielweise einen Growing stack pointer hat oder nicht? oder wie die Datenfeldlänge bestimmter Datentypen unter AROS sind. Für mich allsamt keine Argumente die hinderlich daran sind.

Ansosnten wären für mich diese ganzen configure + --target + --host Corosscompile Dinge ziemlich nutzlos.

[ - Answer - Quote - Direct link - ]
2006-05-01, 01:36 h

DariusBrewka
Posts: 899
[Banned user] 		Hmm, ich vermute mal einfach, dass mir configure sagen will dass das mit einem Crosscompiler nicht funktioniert. Ist auch nicht sonderlich einfach dieses Chinesisch zu verstehen

[ - Answer - Quote - Direct link - ]
2006-05-01, 08:14 h

Mazze
Posts: 263
User 		Ich hänge mich hier mal dran, weil mich das Thema auch interessiert. Das AROS-Build-System kann mit Configure-Paketen umgehen.

So sieht das im mmakerfile.src für LBreakout aus:

code:
%build_with_configure mmake=contrib-games-lbreakout2 nix=yes 
    extraoptions="--with-highscore-path='$$(PROGDIR)data' --with-inst-path='$$(PROGDIR)data' 
    --disable-audio --disable-sdltest --disable-network --with-doc-path='$$(PROGDIR)docs'" 
    prefix=$(CONTRIBDIR)/Games/lbreakout2 nix_dir_layout=no

Vermutlich musst Du noch ein paar Test 'disablen'. Die 'nix'-Option schaltet für Funktionen wie 'fopen' Unix-Pfade ein (z.B. ../../test).
--
AROS - Because every rose has its dorns.
Meine Homepage

[ - Answer - Quote - Direct link - ]
2006-05-01, 12:07 h

Holger
Posts: 8116
User
Zitat:
Original von DariusBrewka:
Ich weiß jetzt nicht wo das Problem sein soll, aber warum soll man unter Linux mit einem Linux Compiler nicht herausfinden könne, ob AROS nun Beispielweise einen Growing stack pointer hat oder nicht?
Ja wie denn?
Ich wüßte nur einen Weg: ein Programm schreiben, das mit dem Stack herumspielt und das Ergebnis ausgibt.
Was ich stattdessen nicht verstehe, warum C-Programmierer nicht einfach Programme schreiben können, die von so einem Systemdetail unabhängig sind. Dann braucht man auch kein configure, daß einem das Machwerk patcht, um es auf anderen Systemen zum Laufen zu bewegen.
Andererseits ist es genausogut möglich, daß das betroffene Programm davon gar nicht abhängt, sondern der Autor selber das Mysterium configure nicht richtig versteht und deshalb alle möglichen überflüssigen Tests aktiviert hat.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2006-05-01, 12:38 h

Mazze
Posts: 263
User
Zitat:
Original von Holger:

Was ich stattdessen nicht verstehe, warum C-Programmierer nicht einfach Programme schreiben können, die von so einem Systemdetail unabhängig sind.

Ziemlich krass war es, als ich vor kurzem ein paar Spiele nach AROS portiert hatte: eine paar KByte Sourcode und fast ein MByte Configure-Geraffel :rotate: . Ich habe mir dann einfach ein kleines Makefile geschrieben.


--
AROS - Because every rose has its dorns.
Meine Homepage

[ - Answer - Quote - Direct link - ]
2006-05-01, 12:42 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Original von Holger:
Ja wie denn?
Ich wüßte nur einen Weg: ein Programm schreiben, das mit dem Stack herumspielt und das Ergebnis ausgibt.

Naja, ich sehe das wieder anders, wenn ich einen Compiler für eine Bestimmte CPU erstelle, dann weiß ich wie diese mit ihren Daten umgeht und kann das in den Compiler direkt integrieren. Man muß ja auch beim Amiga GCC irgendwo festgelegt haben, dass long nicht 8 sondern 4 bytes lang ist. Theoretisch hätte dieses Information in irgendeiner Datei im GCC pfad hinterlegt gewesen sein auf die auch das TestProgramm unter Linux zugreifen könnte. Die Tests werden wohl so ablaufen, dass irgendein TestProgram z.b. printf("%d", sizeof(long)) ausgeben.


[ - Answer - Quote - Direct link - ]
2006-05-02, 17:13 h

Holger
Posts: 8116
User
Zitat:
Original von DariusBrewka:
Naja, ich sehe das wieder anders, wenn ich einen Compiler für eine Bestimmte CPU erstelle, dann weiß ich wie diese mit ihren Daten umgeht und kann das in den Compiler direkt integrieren.
Also.
1) hängt der Stackaufbau nicht allein von der CPU, sondern von CPU und Systemkonvention ab, i.A. als ABI bezeichnet.
2) Ja, dem Compiler wird eben jene Information beigebracht. Aber es gibt keine Möglichkeit, ihn danach zu fragen. Jedenfalls nicht compilerunabhängig, aber Compilerunabhängigkeit ist ja eben das Ziel der configure-Orgien

Zitat:
Man muß ja auch beim Amiga GCC irgendwo festgelegt haben, dass long nicht 8 sondern 4 bytes lang ist.
long ist beim Amiga 4 bytes?
Zitat:
Theoretisch hätte dieses Information in irgendeiner Datei im GCC pfad hinterlegt gewesen sein auf die auch das TestProgramm unter Linux zugreifen könnte.
NEIN. Dann wäre der Sinn von configure ja abhanden gekommen, wenn es nur noch mit gcc, am besten noch von Version x bis Version y funktioniert.
Zitat:
Die Tests werden wohl so ablaufen, dass irgendein TestProgram z.b. printf("%d", sizeof(long)) ausgeben.
Für sizeof kann man sich des Präprozessors bedienen, da der ja schon für die target-Umgebung korrekte header erhalten muß, z.B.

INT_SIZE=$(cpp <<EOF
sizeof(int)
EOF
)

Das heißt, man braucht kein Programm ausführen, man hat den Output ja schon. Für den Test, was bei Stackmanipulationen passiert, geht das eben nicht, weil es dazu, wie schon gesagt, keine Standard-Abfrage gibt.

Da wird wahrscheinlich wirklich ein Programm der Art:
C code:
int a, b;
printf("%d", &a-&b);
Wobei, aus dem Ergebnis irgendwelche Rückschlüsse auf den Stackaufbau zu ziehen, formal gesehen, komplett Banane ist.
Aber wie schon gesagt, ich versteh eh nicht, wieso irgendein normales C Programm diese Information benötigen sollte.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2006-05-03, 09:54 h

gni
Posts: 1106
User
Zitat:
DariusBrewka:
code:
checking for growing stack pointer... configure: error: cannot run test programm while cross compiling
Du hast einfach Pech. Das Programm, das Du zu übersetzen versuchst, ist nicht Cross-Compiler tauglich.

[ - Answer - Quote - Direct link - ]
2006-05-03, 09:58 h

gni
Posts: 1106
User
Zitat:
DariusBrewka:
Ich weiß jetzt nicht wo das Problem sein soll, aber warum soll man unter Linux mit einem Linux Compiler nicht herausfinden könne, ob AROS nun Beispielweise einen Growing stack pointer hat oder nicht? oder wie die Datenfeldlänge bestimmter Datentypen unter AROS sind. Für mich allsamt keine Argumente die hinderlich daran sind.
Der Compiler des Buildsystems kann logischerweise nicht benutzt werden um etwas über die Zielplatform herauszufinden. Das sollte einleuchtend sein.

[ - Answer - Quote - Direct link - ]
2006-05-03, 10:00 h

gni
Posts: 1106
User
Zitat:
Holger:
long ist beim Amiga 4 bytes?
Ich kenne keinen Amiga C-Compiler, der das anders macht.

[ - Answer - Quote - Direct link - ]
2006-05-03, 10:35 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Original von gni:
Der Compiler des Buildsystems kann logischerweise nicht benutzt werden um etwas über die Zielplatform herauszufinden. Das sollte einleuchtend sein.

Es wird in speziellen Fällen wohl so, aber Festgeschrieben ist das nicht und schon garnicht einleuchtend.

[ - Answer - Quote - Direct link - ]
2006-05-03, 11:16 h

gni
Posts: 1106
User
Zitat:
DariusBrewka:
Zitat:
Der Compiler des Buildsystems kann logischerweise nicht benutzt werden um etwas über die Zielplatform herauszufinden. Das sollte einleuchtend sein.
Es wird in speziellen Fällen wohl so, aber Festgeschrieben ist das nicht und schon garnicht einleuchtend.
Ich will garnicht wissen, wo Dein Verständnisproblem ist.

[ - Answer - Quote - Direct link - ]
2006-05-03, 11:42 h

DariusBrewka
Posts: 899
[Banned user]
Zitat:
Original von gni:
Ich will garnicht wissen, wo Dein Verständnisproblem ist.

Sorry, ich gebe die Frage zurück, wie wärs wenn das Programm auf der Build-Plattform übersetzt wird und mir dann einfach gewisse Fragen stellt? ist zwar Blöd aber es ist eine von vielen Möglichkeiten auch auf der Buildplattform etwas über's Ziel zu erfahren.


[ - Answer - Quote - Direct link - ]
2006-05-03, 13:41 h

Holger
Posts: 8116
User
Zitat:
Original von DariusBrewka:
Sorry, ich gebe die Frage zurück, wie wärs wenn das Programm auf der Build-Plattform übersetzt wird und mir dann einfach gewisse Fragen stellt? ist zwar Blöd aber es ist eine von vielen Möglichkeiten auch auf der Buildplattform etwas über's Ziel zu erfahren.
Wenn configure in der Lage wäre, Dich einfach danach zu fragen, wäre es vollkommen unnötig, irgendetwas für die build-plattform zu übersetzen.
Kann es aber nicht, das erklärte Ziel von configure ist ja, eben all dies automatisch herauszufinden. Allerdings hat Mazze ja schon den entscheidenen Hinweis gegeben: Du kannst evtl. eben jene Antworten über Kommandozeilenoptionen an configure übergeben.

Tut mir leid, daß ich Dir dazu keine konkreteren Tipps geben kann. Ich muß mich zum Glück nicht jeden Tag mit configure rumschlagen.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2006-05-03, 15:29 h

gni
Posts: 1106
User
Zitat:
Holger:
Wenn configure in der Lage wäre, Dich einfach danach zu fragen, wäre es vollkommen unnötig, irgendetwas für die build-plattform zu übersetzen.
Übersetzen geht schon - das Ausführen ist das Problem, da Programme von $host nicht auf $build laufen. Cross-compiler erstellen nunmal Programme für "ihr" Target. Daraus kann man lernen, das Software, die während eines configure-Laufes Testprogramme laufen lassen will, nicht per "automatisch" configuriert werden kann.

[ - Answer - Quote - Direct link - ]
2006-05-03, 17:18 h

Holger
Posts: 8116
User
Zitat:
Original von gni:
Übersetzen geht schon - das Ausführen ist das Problem, da Programme von $host nicht auf $build laufen. Cross-compiler erstellen nunmal Programme für "ihr" Target. Daraus kann man lernen, das Software, die während eines configure-Laufes Testprogramme laufen lassen will, nicht per "automatisch" configuriert werden kann.

Ist mir schon klar. Sagte ja nur, daß wenn Darius' Idee, daß das übersetzte Programm dann ihn fragt, was denn nun Sache wäre, man sich das Übersetzen sparen könnte. configure weiß ja, was es fragen will...

Aber davon unabhängig gibt es ja Fragen, die man tatsächlich automatisch (auch bei cross-compilern) beantworten kann, wie z.B. sizeof(int). Das habe ich ja schon oben beschrieben. Der Witz dabei ist allerdings, daß man ja genau solche Tests überhaupt nicht braucht, da sizeof(int) ja sowieso überall im C-Code zur Verfügung steht. Und das ja auch auf höherer Ebene, struct { short int a; int b; long int c; } x; ... sizeof(x) funktioniert sogar besser als irgendein script, das die Größen von Hand ermittelt, reinpatcht und dabei mögliches padding übersieht...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2006-05-03, 23:03 h

DariusBrewka
Posts: 899
[Banned user] 		Theoretisch heißt das (für mich), configure auf der Build-Plattform aufrufen und dann die makefiles für die Target/Host-Plattform anpassen.

Das Ganze Problem war, weil ich configure mit --host=i386-aros aufgerufen habe und configure (zwar nicht in diesem konkreten Fall (growing Stackpointer)) ein Tool für Target (=AROS) compiliert, welches irgendwelche Include Datei erzeugt, unter Linux starten wollte.

[ - Answer - Quote - Direct link - ]
2006-05-04, 00:05 h

Holger
Posts: 8116
User
Zitat:
Original von DariusBrewka:
Theoretisch heißt das (für mich), configure auf der Build-Plattform aufrufen und dann die makefiles für die Target/Host-Plattform anpassen.

Wenn Du nicht die Variante, alle Tests manuell zu "disablen", benutzen willst, kannst Du es natürlich auch so probieren. Ob's klappt, hängt natürlich davon ab, wieviel Abhängigkeiten das Programm zu den Systemeigenheiten (denen, die zwischen Linux und Aros anders sind, natürlich) am Ende wirklich hat.
Möglich wär's.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]

-1- [ - Post reply - ]


amiga-news.de Forum > Programmierung > Open Source Programme übersetzen [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.