|
Anzeige
|
CrossCompile opennssl
Gast
#3837551
Hallo, ich möchte openssl für ARM kompilieren, weiß aber nicht wie. Kann mir jemand bitte helfen? Es gibt da so viele Anleitungen im Internet, aber irgendwie klappt das nicht. Ich brauche openssl-1.0.1g und möchte es für ARM Linux haben. Danke an alle.
Gast
#3837552
Na, was klappt den nicht? Gib mal etwas mehr Infos. Was ist das Hostsystem? Compilerfehler etc... Grüsse, R. > Ich brauche openssl-1.0.1g Sicher? Aktuell ist die 1.0.1i Version. Willst Du alte Bug nachvollziehen? Außerdem ist ARM Linux != ARM Linux. Sowas wie OpenSSL will man normalerweise für die korrekte CPU Variante compilieren.
Gast
#3837934
Oh, dann lade ich mal das aktuelle openSSL runter. Es soll auf einen ARM Cortex A9 laufen. Ich habe Cross-Compile noch nie gemacht. Also irgendwie ./configure --host=ARM-Linux oder so muss das aussehen, nicht?
Gast
#3837938
Sabse schrieb: > Oh, dann lade ich mal das aktuelle openSSL runter. Lade auch gleich den richtigen arm-gcc runter.
Gast
#3837961
Sabse schrieb: > Ich habe Cross-Compile noch nie gemacht. > Also irgendwie ./configure --host=ARM-Linux oder so muss das aussehen, > nicht? Nee, OpenSSL verwendet kein Autoconf. Du musst bei make über die Kommandozeile die CC Variable (und vermutlich noch ein paar andere) auf deinen ARM Compiler umbiegen.
Gast
#3838427
So habe jetzt nochmal für die neue Version gelesen, und da steht man solle beim cross-compilieren erst ./Configure machen, das eine Liste mölicher Architecture liefert. Und dann ./Configure [arch] gefolgt von make. Ich bin mal so frei die Liste hier anzufügen:
Wie gesagt, das soll für ein ARM Cortex A9 mit Linux mit gcc-linaro-arm-linux-gnueabihf_linux sein. Was soll ich denn da wählen? 1) Na dann teste einfach ob configure (nicht: "Configure") diesen Host kennt. 2) Bei --host= würd ich immer auch --build setzen, damit ganz klar gesagt ist, dass es sich um einen Cross-Build handelt. 3) Wenn configure den Host nicht kennt und es sich um ein Standard GNU Build-System handelt, dann gibt es eine config.sub. Erweitere diese für deinen Host. Wenn deine Toolchain Vanilla GCC ist, sollte das genügen. 4) Wenn es absehbar ist, dass du mehrmals neu configuren musst weil die Optionen etc. unklar sind, dann ist ./configure eine schlechte Wahl. Mache den Build von einem leeren Verzeichnis aus, das kein Unterverzeichnis der Quellen ist. Damit hast du mit Löschen des Build-Verzeichnisses tabula rasa. ./configure verpestet dir das Quellverzeichnis, und ob make clean / distclean / realclean oder-was-auch-immer-clean richtig funktionieren ist bei vielen Projekten Russisch Roulette... 5) Was für Build-Verzeichnis gilt, gilt auch für's Installationsverzeichnis. Zunächst eine --prefix wählen die nix kaputt macht und für die man keine Admin sind muss.
Gast
#3840184
Johann L. schrieb: > 1) Na dann teste einfach ob configure (nicht: "Configure") diesen > Host > kennt. Da gibt es nur "config" und "Configure" (grosses C), siehe oben. Wie Testen? > 3) Wenn configure den Host nicht kennt und es sich um ein Standard GNU > Build-System handelt, dann gibt es eine config.sub. Erweitere diese für > deinen Host. Wenn deine Toolchain Vanilla GCC ist, sollte das genügen. config.sub gibt es nicht. Wie oben geschrieben muesste man Configure erweitern, aber das ist mir zu hoch. Sabse schrieb: > Johann L. schrieb: >> 1) Na dann teste einfach ob configure (nicht: "Configure") diesen >> Host >> kennt. > > Da gibt es nur "config" und "Configure" (grosses C), siehe oben. > Wie Testen? > >> 3) Wenn configure den Host nicht kennt und es sich um ein Standard GNU >> Build-System handelt, dann gibt es eine config.sub. Erweitere diese für >> deinen Host. Wenn deine Toolchain Vanilla GCC ist, sollte das genügen. > > config.sub gibt es nicht. > Wie oben geschrieben muesste man Configure erweitern, aber das ist mir > zu hoch. ojeojeoje, hab mal nen Blick in die Quellen riskiert. Configure ist komplett Marke Eigenbau ...immerhin hat man dann was eigenes, wenn die Kinder mal aus dem Haus sind. Was im GNU Build-System config.sub erledigt schein da in config abgearbeitet zu werden anhand von MACHINE, RELEASE, VERSION und BUILD. Es gibt da genug Beispielcode wie verschiedene Systeme abzubilden sind, und CROSS_COMPILE lässt darauf hoffen dass Cross-Compilierung ohne Kopfstand zu machen möglich ist. Schließlich erlaubt Configure die Angabe des Compilers und weiterer Optionen, siehe z.B. Ende von config. Falls das alles zu mühselig ist oder zu unsicher (immerhin soll es ein ssl werden), würd ich mich an die Entwickler wenden. Nicht unüblich dafür sind Mailing-Listen. Die OpenSSL FAQ erwähnt zwar MLs und verweist auf Readme für Details; allerdings scheint es nur eine ML for OpenSSL-Entwickler zu geben, keine für dessen Anwender. Falls du Readme noch nicht gelesen hast, tu es. Dafür ist es da ;-) Dito für INSTALL. Falls das aller immer noch nicht hilft:
Gast
#3840269
Sabse schrieb: > Was soll ich denn da wählen? Nimm linux-armv4, das tut auch auf nem Cortex-A9 schneller als der reine C Code von linux-elf. Bei Interesse kann ich Ergebnisse von "openssl speed" von einem, äh, 800MHz A9 auf Pastebin hochladen.
Gast
#3840270
Google.com...kennste? http://stackoverflow.com/questions/11841919/cross-compile-openssh-for-arm Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
