Installieren und Linking PhysX Bibliotheken in Debian Linux
https://stackoverflow.com/questions/415279
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich versuche, PhysX Arbeit mit Ubuntu zu erhalten.
Zuerst habe ich heruntergeladen das SDK hier:
Als nächstes extrahiert ich die Dateien und installiert jedes Paket mit:
dpkg -i filename.deb
Das gibt mir die folgenden Dateien in /usr/lib/PhysX/v2.8.1 befindet:
- libNxCharacter.so
- libNxCooking.so
- libPhysXCore.so
- libNxCharacter.so.1
- libNxCooking.so.1
- libPhysXCore.so.1
Als nächstes ich erstellt symbolische Links auf / usr / lib:
sudo ln -s /usr/lib/PhysX/v2.8.1/libNxCharacter.so.1 /usr/lib/libNxCharacter.so.1
sudo ln -s /usr/lib/PhysX/v2.8.1/libNxCooking.so.1 /usr/lib/libNxCooking.so.1
sudo ln -s /usr/lib/PhysX/v2.8.1/libPhysXCore.so.1 /usr/lib/libPhysXCore.so.1
Nun, mit Eclipse, ich angegeben habe folgende Bibliotheken (-l):
- libNxCharacter.so.1
- libNxCooking.so.1
- libPhysXCore.so.1
Und die folgenden Suchpfade für alle Fälle (-L):
- /usr/lib/PhysX/v2.8.1
- / usr / lib
Auch, wie Gerald Kaszuba vorgeschlagen, habe ich die folgenden Angaben enthalten Pfade (-I):
- /usr/lib/PhysX/v2.8.1
- / usr / lib
Dann habe ich versucht, den folgenden Code zu kompilieren:
#include "NxPhysics.h"
NxPhysicsSDK* gPhysicsSDK = NULL;
NxScene* gScene = NULL;
NxVec3 gDefaultGravity(0,-9.8,0);
void InitNx()
{
gPhysicsSDK = NxCreatePhysicsSDK(NX_PHYSICS_SDK_VERSION);
if (!gPhysicsSDK)
{
std::cout<<"Error"<<std::endl;
return;
}
NxSceneDesc sceneDesc;
sceneDesc.gravity = gDefaultGravity;
gScene = gPhysicsSDK->createScene(sceneDesc);
}
int main(int arc, char** argv)
{
InitNx();
return 0;
}
Der erste Fehler, den ich bekommen ist:
NxPhysics.h: Keine solche Datei oder das Verzeichnis
Was sagt mir, dass das Projekt offensichtlich nicht richtig verbindet. Kann mir jemand sagen, was ich falsch gemacht habe, oder was sonst noch zu kompilieren ich tun, um mein Projekt zu bekommen? Ich bin mit der GCC C ++ Compiler. Vielen Dank im Voraus!
Lösung
Es sieht aus wie sind Sie Header-Dateien mit Bibliotheksdateien verwirrend. NxPhysics.h ist eine Quellcode-Header-Datei. Header-Dateien benötigt werden, wenn Quellcode kompiliert (nicht bei der Verknüpfung). Es ist wahrscheinlich in einem Ort wie / usr / include oder /usr/include/PhysX/v2.8.1, oder ähnliches. Finden Sie die reale Position dieser Datei und stellen Sie sicher, dass Sie die Option -I verwenden, den Compiler zu sagen, wo es ist, wie Gerald Kaszuba vermuten lässt.
Die Bibliotheken werden benötigt, wenn die Verknüpfung der kompilierten Objektdateien (und nicht beim Kompilieren). Sie werden mit der -L und -l-Optionen mit diesem später befassen müssen.
Hinweis: Je nachdem, wie Sie gcc aufrufen, können Sie es zu tun haben, zusammenzustellen und dann mit einem einzigen Aufruf verbindet, aber hinter den Kulissen tut es immer noch einen Compiler-Schritt dann ein Link Schritt
.EDIT: Zusätzliche Erklärung hinzugefügt ...
Wenn ein binären Aufbau unter Verwendung einer C / C ++ Compiler, liest der Compiler den Quellcode (.c oder CPP-Dateien). Während es zu lesen, gibt es häufig # include-Anweisungen, die Dateien werden verwendet, um lesen .h. Die # include-Anweisungen geben die Namen der Dateien, die geladen werden müssen. Diese genauen Dateien müssen im Pfad enthalten existieren. In Ihrem Fall eine Datei mit dem genauen Namen „NxPhysics.h“ muss irgendwo in dem Include-Pfad gefunden werden. Typischerweise / usr / include ist im Pfad standardmäßig, und so ist das aktuelle Verzeichnis. Wenn die Header irgendwo anders sind wie ein Unterverzeichnis von / usr / include, dann müssen Sie immer explizit den Compiler sagen, wo die -I-Befehlszeilenoptionen verwenden suchen (oder manchmal auch mit Umgebungsvariablen oder anderen Systemkonfigurationsmethoden).
Eine .h Header-Datei enthält typischerweise Datenstruktur Erklärungen, Inline-Funktionsdefinitionen, Funktion und Klassendeklarationen und #define Makros. Wenn die Kompilierung abgeschlossen ist, wird eine .o Objektdatei erstellt. Der Compiler weiß nicht, über .so oder .a Bibliotheken und kann sie nicht in irgendeiner Weise verwenden, außer ein wenig Helfer Informationen für den Linker einzubetten. Beachten Sie, dass der Compiler auch einige „Header“ Informationen in den Objektdateien einbettet. Ich habe „Header“ in Anführungszeichen, weil die Information nur entspricht in etwa dem, was kann oder auch nicht in den H-Dateien zu finden. Es enthält eine binäre Darstellung aller exportierten Erklärungen. Keine Makros sind dort zu finden. Ich glaube, dass Inline-Funktionen als auch weggelassen werden (obwohl ich es falsch sein könnte).
Sobald alle der .o-Dateien vorhanden ist, ist es Zeit für ein anderes Programm zu übernehmen: die Linker. Der Linker weiß nichts von Quellcode-Dateien oder .h Header-Dateien. Es kümmert sich nur um binäre Bibliotheken und Objektdateien. Sie geben ihm eine Sammlung von Bibliotheken und Objektdateien. In ihrem „Header“ sie auflisten, welche Dinge (Datentypen, Funktionen, etc.) sie definieren und welche Dinge, die sie brauchen, jemand anderes zu definieren. Der Linker dann paßt auf Anfragen für Definitionen von einem Modul mit aktuellen Definitionen für andere Module. Es wird überprüft, um sicherzustellen, dass es nicht mehrere widersprüchliche Definitionen sind, und wenn eine ausführbare Datei erstellen, es stellt sicher, dass alle Anforderungen für Definitionen erfüllt sind.
Es gibt einige bemerkenswerte Einschränkungen auf die obige Beschreibung. Zum einen ist es möglich, gcc einmal anrufen und bekommen es sowohl Kompilieren und Linken zu tun, z.
gcc hello.c -o hello
wird zunächst hello.c in den Speicher oder in eine temporäre Datei kompilieren, dann wird es gegen die Standard-Bibliotheken verknüpfen und die hallo ausführbaren auszuschreiben. Auch wenn es nur ein Anruf zu gcc ist, sind beide Schritte noch der Reihe nach, um Sie als Service ausgeführt wird. Ich überspringe werde jetzt einige Details der dynamischen Bibliotheken zu beschreiben.
Wenn Sie ein Java-Programmierer sind, dann einige der oben könnte ein wenig verwirrend sein. Ich glaube, dass .net funktioniert wie Java, so dass die folgende Diskussion auf C # gelten sollte und die anderen .NET-Sprachen. Java ist syntaktisch eine viel einfachere Sprache als C und C ++. Es fehlt Makros und es fehlt echte Vorlagen (Generika eine sehr wea sindk Form des Templates). Aus diesem Grunde, Java überspringt die Notwendigkeit für separate Erklärung (.h) und Definition (.c-Dateien). Es ist auch in der Lage, alle relevanten Informationen in der Objektdatei (.class für Java) einzubetten. Das macht es so, dass sowohl der Compiler und der Linker die .class-Dateien direkt verwenden können.
Andere Tipps
Das Problem war in der Tat mit meinem Pfad enthält. Hier ist der relevante Befehl:
g++ -I/usr/include/PhysX/v2.8.1/SDKs/PhysXLoader/include -I/usr/include -I/usr/include/PhysX/v2.8.1/LowLevel/API/include -I/usr/include/PhysX/v2.8.1/LowLevel/hlcommon/include -I/usr/include/PhysX/v2.8.1/SDKs/Foundation/include -I/usr/include/PhysX/v2.8.1/SDKs/Cooking/include -I/usr/include/PhysX/v2.8.1/SDKs/NxCharacter/include -I/usr/include/PhysX/v2.8.1/SDKs/Physics/include -O0 -g3 -DNX_DISABLE_FLUIDS -DLINUX -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.cpp"
Auch für den Linker, nur "PhysXLoader" benötigt wurden (wie bei Windows). So habe ich:
g++ -o"PhysXSetupTest" ./main.o -lglut -lPhysXLoader
Während der Installation habe ich die folgenden Fehler *
dpkg: dependency problems prevent configuration of libphysx-dev-2.8.1:
libphysx-dev-2.8.1 depends on libphysx-2.8.1 (= 2.8.1-4); however:
Package libphysx-2.8.1 is not configured yet.
dpkg: error processing libphysx-dev-2.8.1 (--install):
dependency problems - leaving unconfigured
Errors were encountered while processing:
* So neu installiert I * libphysx-2.8.1_4_i386.deb *
sudo dpkg -i libphysx-2.8.1_4_i386.deb
