Probleme mit Cross-Compiler

[Marc80]

Moin zusammen,
ich habe ein, wie ich finde, sehr spezielles Problem und ich glaube kaum, dass mir jemand aus dem Stehgreif dabei weiterhelfen kann, aber da ich ziemlich verzweifelt bin probier ich es trotzdem mal.

Folgendes Problem:
Ich habe vor, einen bereits vorhandenen minimalen Webserver (in Java programmiert) um SSL-Fähigkeit zu erweitern. Dies ist erstmal in Java das geringste Problem. Prinzipiell bin ich damit auch schon fertig und der Webserver läuft.
Allerdings soll der Webserver später nich auf einem PC laufen, sondern auf einem Embedded Board mit ARM-Prozessor. Für diesen gibt es einen Crosscompiler, er auf dem GCJ aufbaut und aus Java-Quellcode nativen Maschinencode produzieren kann.
Dieser Crosscompiler ist allerdings nur Java 1.2-kompatibel, so dass sämtliche SSL-Klassen fehlen. Dieses Problem will ich umgehen, indem ich die freie Klassenbibliothek Jessie verwende. Diese ist laut Entwickler auch GCJ-kompatibel.

Der Crosscompiler ist unter Cygwin intsalliert und funktioniert auch prinzipiell. Aber wenn ich mein Programm mit dem Befehl

arm-linux-gcj -static --main=WebServer WebServer.java -o webs

übersetzen will erhalte ich folgende Fehlermeldung:

/cygdrive/c/DOKUME~1/mheister/LOKALE~1/Temp/ccC5PASV.o(.text+0x3180): In functio
n `WebServer::main(JArray<java::lang::String*>*)':
WebServer.java: undefined reference to `javax::net::ssl::KeyManagerFactory::getI
nstance(java::lang::String*)'
/cygdrive/c/DOKUME~1/mheister/LOKALE~1/Temp/ccC5PASV.o(.text+0x31c0):WebServer.j
ava: undefined reference to `javax::net::ssl::KeyManagerFactory::init(java::secu
rity::KeyStore*, JArray<wchar_t>*)'
/cygdrive/c/DOKUME~1/mheister/LOKALE~1/Temp/ccC5PASV.o(.text+0x31cc):WebServer.j
ava: undefined reference to `javax::net::ssl::SSLContext::getInstance(java::lang
::String*)'
/cygdrive/c/DOKUME~1/mheister/LOKALE~1/Temp/ccC5PASV.o(.text+0x321c):WebServer.j
ava: undefined reference to `javax::net::ssl::KeyManagerFactory::getKeyManagers(
)'
/cygdrive/c/DOKUME~1/mheister/LOKALE~1/Temp/ccC5PASV.o(.text+0x3234):WebServer.j
ava: undefined reference to `javax::net::ssl::SSLContext::init(JArray<javax::net
::ssl::KeyManager*>*, JArray<javax::net::ssl::TrustManager*>*, java::security::S
ecureRandom*)'
/cygdrive/c/DOKUME~1/mheister/LOKALE~1/Temp/ccC5PASV.o(.text+0x325c):WebServer.j
ava: undefined reference to `javax::net::ssl::SSLContext::getServerSocketFactory
()'
/cygdrive/c/DOKUME~1/mheister/LOKALE~1/Temp/ccC5PASV.o(.text+0x3674):WebServer.j
ava: undefined reference to `javax::net::ssl::SSLServerSocket::class$'
collect2: ld returned 1 exit status

Das Kompilieren und das Assemblieren des Quelltextes funktioniert ohne Fehlermeldungen, aber wenn man kompilieren, assemblieren UND linken will (was für ein lauffähiges Programm natürlich vorraussetzung ist) erhalte ich diese Fehler.
Ach ja: Bevor ich die SSL-Erweiterungen eingebaut hatte ließ sich der Webserver mit dem Crosscompiler übersetzen.

Da das Programm sich ja eigentlich normal übersetzen lässt (zumindest mit einem normalen JDK) werde ich an dieser Stelle auch erstmal keinen Quellcode posten. Mich würde überhaupt erst einmal interessieren, wie ich diese Fehlermeldungen deuten kann und wie ich jetzt weiter bei der Fehleranalyse vorgehen kann.

Ich danke Euch auf jeden Fall schon mal im Vorraus!

Marc

 

[KISS]

vermutung 1:
ueberfluessige imports (javax.net.ssl) rausnehmen, oder du nutzt noch legacy classes von sun

vermutung 2:
die jessie macher ertreisten sich ihre packages unter javax zu publizieren und du hast die externen jars nicht richtig angeben

regards

 

[Marc80]

Danke erstmal für die Antwort.

Die jessie-Macher erdreisten sich tatsächlich ihre packages unter javax zu publizieren. Wahrscheinlich, damit man keine Änderungen am Quelltext vornehmen muss wenn man vorher JSSE oder ein JDK => 1.4 verwendet hat.

Dass ich die Klassenbibliothek irgendwie "falsch" benutze kann ich mir nicht vorstellen, denn sonst ließe sich das ganze mit dem normalen JDK1.2 nicht übersetzen. Ich habs auch schon mit nem jar-File probiert, das ich im Classpath angegeben hab und direkt mit den Sources der Classlib. Hat beides denselben Effekt.

javax.net.ssl kann ich auch nicht aus den imports rausnehmen weil, wie gesagt, der ganze Kram unter javax publiziert wurde. Zu Konflikten kann es dabei auch nicht kommen weil im JDK1.2 javax.net komplett fehlt.

 

[KISS]

aeh, na so was aber auch. damit laeufst du genau in die falle, die man eigentlich nicht will. schau mal ob man bei dem compiler den bootclasspath mit angeben kann, da muestest du dann mit prepend das jessi jar mit angeben da sonst normal die sun klassen benutzt werden