planetquake.eu

Ich verzweifle langsam und bin mit meinem Latein schon längst am Ende..
Bin leider nicht so der Linux-Spezialist, als dass ich solchen Sachen genauer auf den Grund gehen könte - die meisten Fehlermeldungen bzw. ihre Ursache versteh ich nämlich schon nicht

Hab hier ein C-Programm, das will ich für 'ne Arm CPU compilieren.. aber so weit komme ich noch nichtmal, denn selbst mit 'nem gewöhnlichen g++ Compile haut das schon nicht hin, weil er Include-Files nicht findet, obwohl ich ihm das Include-Verzeichnis angegeben hab..

Das sind sowieso Dinge, die ich noch nicht so ganz verstehe..
Gibt's nicht eine Variable, analog zu $PATH, in der ich alle Include-Verzeichnisse angeben kann? Hab im Netz irgendwas mit LD_LIBRARY_PATH gefunden, das hat aber auch nichts bewirkt..

Oder was der Unterschied zwischen "cmake" und "make" ist..

Google meint zu cmake es sei "Crossplatform"-Make.

Wegen den includefiles, das gibs afaik nen standard ordner nämlich /usr/include
Das is glaub ich, weil die meisten Linuxe/Unixe sich an den Filesystem Hierarchy Standard halten.

Es gibt auch noch nen include verzeichnis in /opt aber ich glaub das is für was anderes da

Ob das dein Problem jetz ab lst weiß ich ned

Auf /usr/include bin ich bei meiner Suche auch gestoßen, jedoch ist mir noch nicht klar, wie die Dateien da hin kommen..
Sorgen die Installations- bzw. Compilierungsskripte selbst dafür (dann würde in meinem Fall irgendwas fehlschlagen) oder muss ich die Header-Files selbst da hin kopieren?

Vielleicht werde ich mal etwas konkreter, weil offenbar viele diesen Thread gelesen haben, aber sich denken "keine Ahnung wovon der spricht, bloß weg hier"

Ich habe ein C-Programm, das auf die Bibliothek OpenCV zugreift - dieses C-Programm soll nun mit Hilfe des Java Native Interfaces für Arm-Prozessoren compiliert werden, so dass ich es in meinem Java-Programm (welches ich mit Hilfe des Android SDKs entwickelt habe) verwenden kann..

Dazu habe ich viele verschiedene Wege probiert..
Erster Anlauf (offizielle Anleitung)
Versuch 2
Die URL zum 3. Tutorial finde ich leider gerade nicht..
heutiger Anlauf #4 (neue offizielle Anleitung)

Die Beispiele, die in den Tutorials erwähnt werden, lassen sich auch alle wunderbar compilieren.. nur wenn ich mein eigenes Programm aufbauen möchte, weiß ich nicht so recht was ich alles benötige..
Da gibt's diese ".mk" Dateien, dann "default.properties" und weiter diese "CMakeLists.txt".. manchmal kann ich "make" eingeben, in anderen Verzeichnissen klappt das nicht.. ich blick halt überhaupt nicht durch was wofür gut ist
Wenn man sein Leben lang mit IDEs programmiert, die solche Sachen entweder selbst erledigen oder übersichtliche Optionsmenüs anbieten, in denen man das bequem einstellen kann, ist das ein Sprung ins kalte Wasser, wenn man dann auf einmal mit Kommandozeilen-Tools hantieren muss - und dann auch noch auf 'nem System, mit dem man sich nur oberflächlich auskennt

Ich weiß halt nicht in welchem Schritt genau er die Bibliotheken erstellt und wo ich sie anschließend finden müsste.. geschweige denn wie sie heißen..
Meine Vermutung ist, dass sie die Dateiendung .so haben müssten (weil die meisten Bibliotheken so enden), aber ich find halt kein Indiz dafür..

Im 1. Schritt würde mir auch erstmal reichen, das überhaupt unter Linux compiliert zu kriegen.. haut nämlich auch schon nicht hin..

Hiho Evilchen!

Der Reihe nach:

'cmake' ist cmake - eigentlich eine Art meta-make, das plattformspezifische Makefiles generiert. 'make' ist meist ein Alias oder Symlink auf das plattformspezifische default-make (davon gibt es leider fast so viele, wie es Build-Systeme gibt ), unter GNU/Linux demnach zumeist GNU make. cmake generiert anhand der CMakeLists.txt also Makefiles fuer GNU make, welches dir dann deinen Compiler, Linker, etc. aufruft. Ich habe mit cmake noch nie selbst gearbeitet, sondern ihm bisher nur beim Bauen von KDE-Anwendungen zugesehen. Insofern kann ich dazu auch nichts Schlaues erzaehlen, was mir im Herzen weh tut

Zu den umgebungsvariablen: PATH ist eine durch Doppelpunkte separierte Liste von Verzeichnissen, die von deiner Shell und einer Hand voll C-Funktionen (allen aus der exec-Familie z. B.) nach ausfuehrbaren Dateien durchsucht wird, wenn du eine solche ohne genaue Pfadangabe starten willst. LD_LIBRARY_PATH ist im sehr Groben sowas aehnliches - wieder eine Liste mit einer Syntax wie der von PATH, in der du den dynamischen Linker (ld) deines Systems zur Laufzeit - mit dem Build-Prozess hat das nichts zu tun! - anweisen kannst, in den in ihr angefuehrten Verzeichnissen nach Shared Objects (.so-Files) zu suchen. Ein .so ist eine grobe Entsprechung zu einer DLL unter Win32.

Wenn du gcc oder g++ manuell aufrufst, kannst du einzelne Bibliotheken mit "-l" (kleines el) vom Linker (dynamisch) dazulinken lassen. Dabei entfaellt der "lib"-Praefix - wenn du ein Programm also mit der Bibliothek "libm" linken willst, kompilierst du es bspw. so: 'gcc -lm sourcefile.c'. Der -L-Parameter (groszes el) nimmt Verzeichnisse entgegen, die auf der Suche nach diesen Bibliotheken abgegrast werden sollen. Beide Parameter kann man mehrfach angeben, um mehr als eine Bibliothek bzw. mehr als ein Suchverzeichnis zur Liste hinzuzufuegen. Kann aber durchaus sein, dass dir deine Build-Umgebung das haendische Zusammensuchen von all dem Krempel irgendwie abnehmen kann.

Summa summarum muesste ich wohl (mindestens) einen Blick auf den Output deiner Build-Versuche werfen, um eine Vermutung abgeben zu koennen, woran es letztendlich wirklich hakt. Laesst sich das machen, oder ist das Top Secret?

Großen Dank für die Ausführung, dadurch ist mir einiges klarer geworden..

Nur den genauen Unterschied zwischen .lib und .so verstehe ich noch nicht..
Hat das evtl. was mit dynamischen und statischen Bibliotheken zu tun?

Also wenn ich das bisher verstanden hab, hab ich mit "cmake" zunächst die nötige make-"Konfiguration" für OpenCV erstellt und dann mit "make" den eigentlich Buildprozess angestoßen..
Okay.. das heißt irgendwo müssten dann nach Abschluss des "make" die .libs oder .sos liegen..
Habe mit "locate cv.lib" und "locate cv.so" (er findet ja auch Teilstrings, also wenn die libcv.so" heißen würde, würde er sie auch auflisten) nach potenziellen Bibliotheken gesucht, aber nichts gefunden..

Und allgemein verstehe ich auch noch nicht, wie genau man dieses Java Native Interface nutzt..
Da gibt es ein Skript namens "ndk-build", welches ich wohl durch irgendeine vorhergehende Aktion so konfiguriert habe, dass er mein Programm compilieren will - zumindest gibt er das Verzeichnis und den Dateinamen meines ersten Versuchs aus
Der meldet jedoch auch "/foo/bar/code.cpp:10:16: error: cv.h: No such file or directory"..

Also .lib ist keine Dateiendung, die auf GNU/Linux irgendeine besondere Rolle spielt - im Gegensatz zu z. B. .so. Eine wichtige Konvention ist, dass Bibliothekennamen mit "lib" beginnen ("lib" also als Praefix im Dateinamen fuehren), man diesen Teilstring aber beim Linken-Lassen weglaesst (-lm linkt libm, -liberty linkt libiberty, etc.). Ob du eine Library statisch oder dynamisch gegen deine Binary linkst, bleibt dir ueberlassen (GCC-Option "-static"). Statisch gelinkte Libraries werden wirklich in die ELF-Binary, die dir der Compiler/Linker rausschreibt, reinkopiert, dynamisch gelinkte Libraries sucht sich ld zur Laufzeit deines Programms zusammen. Ob eine Binary statisch oder dynamisch gelinkt ist, kann dir z. B. das Programm 'file' sagen (es interpretiert dazu den ELF-Header der Datei). Gegen welche dynamisch gelinkten Libraries eine Binary linkt, kann dir das Programm 'ldd' sagen. Beide wollen als Argumente Pfade zu den Dateien, deren Eigenschaften dich interessieren.

Ob nach einem 'make' irgendwo unter deinem working directory Libraries oder Binaries rumfliegen, wird einzig durch das Makefile bestimmt. Ich kann mir zwar nicht vorstellen, dass das Projekt da absichtlich nix uebrig laesst, aber prinzipiell _moeglich_ ist es durchaus... Mit 'locate' nach den Files zu suchen wird aber alleine schon deshalb fruchtlos enden, da dieses Programm nicht das Dateisystem ad hoc, sondern einen periodisch auf Stand gebrachten Index das Dateisystems durchsucht. 'find . -iname "*.so"' koennte dir eventuell was offenbaren, das locate (noch) nicht kennt.

Zu JNI kann ich leider generell nichts sagen, da ich es noch nie verwenden musste.

Also ich flipp echt aus.. kann es sein, dass der OpenCV Quellcode im aktuellen Repository irgendwo zerschossen ist?

Habe mir den aktuellen Code geholt..
Offenbar geht die alte hier erwähnte Methode mit dem "cmake .." nicht mehr, stattdessen haben sie 'n Skript cmake_android.sh bzw. cmake_android_armeabi.sh da hingelegt..
Habe "sh cmake_android.sh" ausgeführt, der erstellt mir 'n build Verzeichnis und meldet, dass er's erfolgreich abgeschlossen hat..
Dann wechsle ich ins build Verzeichnis und da drin rufe ich einfach "make" auf.. oder sehe ich das falsch?
Er beginnt jedenfalls dann zu compileren.. bricht aber irgendwo bei 69% ab..


Es treibt mich echt in den Wahnsinn..

Habe schon die Zeile, die er anmeckert auskommentiert und dann baut er tatsächlich bis zum Ende auf, aber ich habe weder eine Ahnung was das für Folgen haben könnte, noch brachte es mich im Endeffekt weiter, da er beim Compilieren meiner Anwendung wieder meckert, dass irgendwas nicht gefunden wurde


Im letzten Abschnitt sieht es sogar fast so aus, als sei der Fehler in meinem Programm.. auf meinem Windows-Rechner hier compiliert er's in Eclipse aber ohne kleinstes Problem..
Er findet also offensichtlich IplImage nicht und weiß daher auch nichts weiter damit anzufangen..

Ich tippe auf eine falsche Version der benötigten Libraries. Da ich das Programm nicht kenne, kann ich aber keine konkreten Empfehlungen geben. Der Entwickler sollte es aber irgendwo im Quelltext-Paket oder auf seiner Webseite mitteilen, was genau gebraucht wird.

Btw: Warum Screenshots, wenn du einfach die Konsolenausgabe kopieren & einfügen könntest?