Installazione e collegamento delle librerie PhysX in Debian Linux
https://stackoverflow.com/questions/415279
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Sto cercando di far funzionare PhysX usando Ubuntu.
Innanzitutto, ho scaricato l'SDK qui:
Successivamente, ho estratto i file e ho installato ciascun pacchetto con:
dpkg -i filename.deb
Questo mi dà i seguenti file che si trovano in /usr/lib/PhysX/v2.8.1:
- libNxCharacter.so
- libNxCooking.so
- libPhysXCore.so
- libNxCharacter.so.1
- libNxCooking.so.1
- libPhysXCore.so.1
Successivamente, ho creato collegamenti simbolici a / 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
Ora, usando Eclipse, ho specificato le seguenti librerie (-l):
- libNxCharacter.so.1
- libNxCooking.so.1
- libPhysXCore.so.1
E i seguenti percorsi di ricerca nel caso (-L):
- /usr/lib/PhysX/v2.8.1
- / usr / lib
Inoltre, come suggerito da Gerald Kaszuba, ho aggiunto i seguenti percorsi include (-I):
- /usr/lib/PhysX/v2.8.1
- / usr / lib
Quindi, ho provato a compilare il seguente codice:
#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;
}
Il primo errore che ottengo è:
NxPhysics.h: nessun file o directory
Il che mi dice che il progetto ovviamente non sta collegando correttamente. Qualcuno può dirmi cosa ho fatto di sbagliato, o cos'altro devo fare per far compilare il mio progetto? Sto usando il compilatore GCC C ++. Grazie in anticipo!
Soluzione
Sembra che tu stia confondendo i file di intestazione con i file di libreria. NxPhysics.h è un file di intestazione del codice sorgente. I file di intestazione sono necessari durante la compilazione del codice sorgente (non durante il collegamento). Probabilmente si trova in un posto come / usr / include o /usr/include/PhysX/v2.8.1 o simili. Trova la posizione reale di questo file e assicurati di utilizzare l'opzione -I per dire al compilatore dove si trova, come suggerisce Gerald Kaszuba.
Le librerie sono necessarie quando si collegano i file degli oggetti compilati (e non durante la compilazione). Dovrai occupartene in seguito con le opzioni -L e -l.
Nota: a seconda di come invocare gcc, puoi farlo compilare e poi collegare con una singola invocazione, ma dietro le quinte fa ancora una fase di compilazione quindi una fase di collegamento.
MODIFICA: spiegazione aggiuntiva aggiunta ...
Quando si crea un binario usando un compilatore C / C ++, il compilatore legge il codice sorgente (file .c o .cpp). Durante la lettura, ci sono spesso istruzioni #include che vengono utilizzate per leggere i file .h. Le istruzioni #include forniscono i nomi dei file che devono essere caricati. Quei file esatti devono esistere nel percorso include. Nel tuo caso, un file con il nome esatto " NxPhysics.h " deve essere trovato da qualche parte nel percorso include. In genere, / usr / include si trova nel percorso per impostazione predefinita, così come la directory corrente. Se le intestazioni sono da qualche altra parte come una sottodirectory di / usr / include, allora devi sempre dire esplicitamente al compilatore dove cercare usando le opzioni della riga di comando -I (o talvolta con variabili d'ambiente o altri metodi di configurazione del sistema).
Un file di intestazione .h in genere include dichiarazioni di strutture di dati, definizioni di funzioni incorporate, dichiarazioni di funzioni e classi e macro #define. Al termine della compilazione, viene creato un file oggetto .o. Il compilatore non conosce le librerie .so o .a e non può usarle in alcun modo, se non per incorporare un po 'di informazioni di supporto per il linker. Nota che il compilatore incorpora anche alcune "intestazioni" informazioni nei file oggetto. Ho inserito " header " tra virgolette perché le informazioni corrispondono solo approssimativamente a ciò che può o non può essere trovato nei file .h. Include una rappresentazione binaria di tutte le dichiarazioni esportate. Non ci sono macro lì. Credo che anche le funzioni inline siano omesse (anche se potrei sbagliarmi lì).
Una volta che tutti i file .o esistono, è tempo che un altro programma prenda il sopravvento: il linker. Il linker non sa nulla dei file di codice sorgente o dei file di intestazione .h. Si preoccupa solo delle librerie binarie e dei file oggetto. Gli dai una raccolta di librerie e file oggetto. Nelle loro "intestazioni" elencano quali cose (tipi di dati, funzioni, ecc.) definiscono e quali cose hanno bisogno di qualcun altro per definire. Il linker quindi abbina le richieste di definizioni da un modulo con le definizioni effettive per altri moduli. Verifica che non vi siano più definizioni in conflitto e, se si crea un eseguibile, si assicura che tutte le richieste di definizioni siano soddisfatte.
Ci sono alcuni avvertimenti notevoli nella descrizione sopra. Innanzitutto, è possibile chiamare gcc una volta e farlo compilare e collegare, ad esempio
gcc hello.c -o hello
compilerà prima ciao.c in memoria o in un file temporaneo, quindi si collegherà alle librerie standard e scriverà l'eseguibile ciao. Anche se è solo una chiamata a gcc, entrambi i passaggi vengono ancora eseguiti in sequenza, per comodità. Per ora, non descriverò alcuni dettagli delle librerie dinamiche.
Se sei un programmatore Java, alcune delle precedenti potrebbero essere un po 'confuse. Credo che .net funzioni come Java, quindi la seguente discussione dovrebbe applicarsi a C # e agli altri linguaggi .net. Java è sintatticamente un linguaggio molto più semplice di C e C ++. Manca di macro e manca di modelli reali (i generici sono una forma molto debole di modelli). Per questo motivo, Java salta la necessità di file separati di dichiarazione (.h) e definizione (.c). È anche in grado di incorporare tutte le informazioni rilevanti nel file oggetto (.class per Java). In questo modo, sia il compilatore che il linker possono utilizzare direttamente i file .class.
Altri suggerimenti
Il problema era in effetti con i miei percorsi include. Ecco il comando pertinente:
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"
Inoltre, per il linker, solo " PhysXLoader " era necessario (uguale a Windows). Quindi, ho:
g++ -o"PhysXSetupTest" ./main.o -lglut -lPhysXLoader
Durante l'installazione ho ricevuto il seguente errore *
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:
* Quindi ho reinstallato * libphysx-2.8.1_4_i386.deb *
sudo dpkg -i libphysx-2.8.1_4_i386.deb
