Installer et relier des bibliothèques PhysX dans Debian Linux

Question

J'essaie de faire fonctionner PhysX avec Ubuntu.

D'abord, j'ai téléchargé le SDK ici:

• http://developer.download. nvidia.com/PhysX/2.8.1/PhysX_2.8.1_SDK_CoreLinux_deb.tar.gz

Ensuite, j'ai extrait les fichiers et installé chaque paquet avec:

dpkg -i filename.deb

Cela me donne les fichiers suivants situés dans /usr/lib/PhysX/v2.8.1:

• libNxCharacter.so
• libNxCooking.so
• libPhysXCore.so
• libNxCharacter.so.1
• libNxCooking.so.1
• libPhysXCore.so.1

Ensuite, j'ai créé des liens symboliques vers / 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

Maintenant, en utilisant Eclipse, j'ai spécifié les bibliothèques suivantes (-l):

• libNxCharacter.so.1
• libNxCooking.so.1
• libPhysXCore.so.1

Et les chemins de recherche suivants au cas où (-L):

• /usr/lib/PhysX/v2.8.1
• / usr / lib

De plus, comme Gerald Kaszuba l’a suggéré, j’ai ajouté les chemins d’inclusion suivants (-I):

• /usr/lib/PhysX/v2.8.1
• / usr / lib

Ensuite, j'ai tenté de compiler le code suivant:

#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;
}

La première erreur que je reçois est:

  

NxPhysics.h: Aucun fichier ni répertoire de ce type

Ce qui me dit que le projet ne relie évidemment pas correctement. Quelqu'un peut-il me dire ce que j'ai mal fait ou ce qu'il me reste à faire pour que mon projet soit compilé? J'utilise le compilateur GCC C ++. Merci d'avance!

Answer 1

On dirait que vous confondez les fichiers d’en-tête avec les fichiers de bibliothèque. NxPhysics.h est un fichier d'en-tête de code source. Les fichiers d'en-tête sont nécessaires lors de la compilation du code source (pas lors de la liaison). Il est probablement situé dans un endroit comme / usr / include ou /usr/include/PhysX/v2.8.1, ou similaire. Recherchez l'emplacement réel de ce fichier et assurez-vous d'utiliser l'option -I pour indiquer au compilateur où il se trouve, comme le suggère Gerald Kaszuba.

Les bibliothèques sont nécessaires lors de la liaison des fichiers d'objet compilés (et non lors de la compilation). Vous devrez vous en occuper plus tard avec les options -L et -l.

Remarque: en fonction de la manière dont vous appelez gcc, vous pouvez le faire compiler puis lier avec un seul appel, mais en coulisse, il effectue toujours une étape de compilation puis une étape de lien.

EDIT: Une explication supplémentaire a été ajoutée ...

Lors de la construction d'un fichier binaire à l'aide d'un compilateur C / C ++, le compilateur lit le code source (fichiers .c ou .cpp). Lors de la lecture, il existe fréquemment des instructions #include utilisées pour lire les fichiers .h. Les instructions #include donnent les noms des fichiers qui doivent être chargés. Ces fichiers exacts doivent exister dans le chemin d'inclusion. Dans votre cas, un fichier portant le nom exact " NxPhysics.h " doit être trouvé quelque part dans le chemin d’inclusion. Typiquement, / usr / include est dans le chemin par défaut, tout comme le répertoire en cours. Si les en-têtes se trouvent ailleurs, par exemple dans un sous-répertoire de / usr / include, vous devez toujours indiquer explicitement au compilateur où regarder à l'aide des commutateurs de ligne de commande -I (ou parfois de variables d'environnement ou d'autres méthodes de configuration système).

Un fichier d'en-tête .h comprend généralement des déclarations de structure de données, des définitions de fonction en ligne, des déclarations de fonction et de classe et des macros #define. Lorsque la compilation est terminée, un fichier objet .o est créé. Le compilateur ne connaît pas les bibliothèques .so ou .a et ne peut les utiliser d'aucune façon, sauf pour incorporer un peu d'informations d'aide pour l'éditeur de liens. Notez que le compilateur incorpore également des "en-têtes". informations dans les fichiers objets. Je mets " en-tête " entre guillemets, car les informations ne correspondent qu'en gros à ce que l’on peut trouver ou non dans les fichiers .h. Il comprend une représentation binaire de toutes les déclarations exportées. Aucune macro ne se trouve là. Je crois que les fonctions en ligne sont également omises (bien que je puisse me tromper là-bas).

Une fois que tous les fichiers .o existent, il est temps qu'un autre programme prenne le relais: l'éditeur de liens. L'éditeur de liens ne sait rien des fichiers de code source ou des fichiers d'en-tête .h. Il ne s'intéresse qu'aux bibliothèques binaires et aux fichiers objets. Vous lui donnez une collection de bibliothèques et de fichiers objets. Dans leurs "en-têtes" ils répertorient les éléments qu'ils définissent (types de données, fonctions, etc.) et ceux qu'ils doivent définir. L'éditeur de liens met ensuite en correspondance les demandes de définitions émanant d'un module avec les définitions réelles d'autres modules. Il vérifie qu'il n'y a pas plusieurs définitions en conflit et, lors de la construction d'un exécutable, il s'assure que toutes les demandes de définitions sont satisfaites.

Il y a quelques réserves notables à la description ci-dessus. Tout d’abord, il est possible d’appeler gcc une fois et de le faire compiler et lier, par exemple

.

gcc hello.c -o hello

va d'abord compiler hello.c en mémoire ou dans un fichier temporaire, puis se liera aux bibliothèques standard et écrira l'exécutable hello. Même s'il ne s'agit que d'un appel à gcc, les deux étapes sont toujours exécutées de manière séquentielle, pour votre commodité. Je vais sauter de décrire quelques détails des bibliothèques dynamiques pour le moment.

Si vous êtes un programmeur Java, certaines des réponses ci-dessus risquent d’être un peu déroutantes. Je pense que .net fonctionne comme Java, la discussion suivante devrait donc s'appliquer à C # et aux autres langages .net. Java est syntaxiquement un langage beaucoup plus simple que C et C ++. Il manque des macros et de vrais modèles (les génériques sont une forme très faible de modèles). De ce fait, Java ne nécessite pas de fichiers de déclaration (.h) et de définition (.c) séparés. Il est également capable d'intégrer toutes les informations pertinentes dans le fichier objet (.class for Java). Cela permet au compilateur et à l'éditeur de liens d'utiliser directement les fichiers .class.

Answer 2

Le problème était bien avec mes chemins d'inclusion. Voici la commande 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"

De même, pour l'éditeur de liens, seul "PhysXLoader". était nécessaire (identique à Windows). Ainsi, j'ai:

g++  -o"PhysXSetupTest"  ./main.o   -lglut -lPhysXLoader

Answer 3

Lors de l'installation, j'ai l'erreur suivante. *

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:

* J'ai donc réinstallé * libphysx-2.8.1_4_i386.deb *

sudo dpkg -i libphysx-2.8.1_4_i386.deb