Instalando y enlazando bibliotecas PhysX en Debian Linux
https://stackoverflow.com/questions/415279
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Estoy intentando que PhysX funcione con Ubuntu.
Primero, descargué el SDK aquí:
A continuación, extraje los archivos e instalé cada paquete con:
dpkg -i filename.deb
Esto me da los siguientes archivos ubicados en /usr/lib/PhysX/v2.8.1:
- libNxCharacter.so
- libNxCooking.so
- libPhysXCore.so
- libNxCharacter.so.1
- libNxCooking.so.1
- libPhysXCore.so.1
A continuación, creé enlaces simbólicos 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
Ahora, usando Eclipse, he especificado las siguientes bibliotecas (-l):
- libNxCharacter.so.1
- libNxCooking.so.1
- libPhysXCore.so.1
Y las siguientes rutas de búsqueda por si acaso (-L):
- /usr/lib/PhysX/v2.8.1
- / usr / lib
Además, como sugirió Gerald Kaszuba, agregué las siguientes rutas de acceso (-I):
- /usr/lib/PhysX/v2.8.1
- / usr / lib
Luego, intenté compilar el siguiente código:
#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;
}
El primer error que recibo es:
NxPhysics.h: No existe tal archivo o directorio
Lo que me dice que el proyecto, obviamente, no está enlazando correctamente. ¿Alguien puede decirme qué he hecho mal o qué más debo hacer para que mi proyecto se compile? Estoy usando el compilador GCC C ++. Gracias de antemano!
Solución
Parece que estás confundiendo archivos de cabecera con archivos de biblioteca. NxPhysics.h es un archivo de encabezado de código fuente. Los archivos de encabezado son necesarios cuando se compila el código fuente (no cuando se vincula). Probablemente esté ubicado en un lugar como / usr / include o /usr/include/PhysX/v2.8.1, o similar. Encuentre la ubicación real de este archivo y asegúrese de usar la opción -I para decirle al compilador dónde está, como sugiere Gerald Kaszuba.
Las bibliotecas son necesarias cuando se vinculan los archivos de objetos compilados (y no cuando se compilan). Tendrá que lidiar con esto más adelante con las opciones -L y -l.
Nota: dependiendo de cómo invocas gcc, puedes hacer que compile y luego se vincule con una sola invocación, pero entre bambalinas sigue haciendo un paso de compilación y luego un enlace.
EDITAR: Se agregó una explicación adicional ...
Al compilar un binario utilizando un compilador C / C ++, el compilador lee el código fuente (archivos .c o .cpp). Mientras lo lee, con frecuencia hay #include sentencias que se usan para leer archivos .h. Las instrucciones #include dan los nombres de los archivos que deben cargarse. Esos archivos exactos deben existir en la ruta de inclusión. En su caso, un archivo con el nombre exacto '' NxPhysics.h '' debe encontrarse en algún lugar de la ruta de inclusión. Normalmente, / usr / include está en la ruta por defecto, y también lo es el directorio actual. Si los encabezados están en algún otro lugar, como un subdirectorio de / usr / include, entonces siempre debe indicar explícitamente al compilador dónde buscar con los modificadores de la línea de comandos -I (o algunas veces con variables de entorno u otros métodos de configuración del sistema).
Un archivo de encabezado .h generalmente incluye declaraciones de estructura de datos, definiciones de funciones en línea, declaraciones de funciones y clases y #define macros. Cuando se realiza la compilación, se crea un archivo de objeto .o. El compilador no conoce las bibliotecas .so o .a y no puede usarlas de ninguna otra manera que no sea para incrustar un poco de información auxiliar para el enlazador. Tenga en cuenta que el compilador también incrusta algún " encabezado " Información en los archivos objeto. Puse " encabezado " entre comillas porque la información solo corresponde aproximadamente a lo que se puede encontrar o no en los archivos .h. Incluye una representación binaria de todas las declaraciones exportadas. No se encuentran macros allí. Creo que las funciones en línea también se omiten (aunque podría estar equivocado).
Una vez que todos los archivos .o existen, es hora de que otro programa se haga cargo: el enlazador. El enlazador no sabe nada de archivos de código fuente o archivos de cabecera .h. Solo se preocupa por bibliotecas binarias y archivos de objetos. Le das una colección de bibliotecas y archivos de objetos. En sus " encabezados " enumeran qué cosas (tipos de datos, funciones, etc.) definen y qué cosas necesitan que otra persona defina. El enlazador luego compara las solicitudes de definiciones de un módulo con las definiciones reales de otros módulos. Comprueba para asegurarse de que no haya múltiples definiciones en conflicto, y si crea un ejecutable, se asegura de que se cumplan todas las solicitudes de definiciones.
Hay algunas advertencias notables a la descripción anterior. Primero, es posible llamar a gcc una vez y hacer que compile y enlace, por ejemplo,
gcc hello.c -o hello
primero compilará hello.c en la memoria o en un archivo temporal, luego se vinculará con las bibliotecas estándar y escribirá el ejecutable hello. Aunque solo se trata de una llamada a gcc, ambos pasos se siguen realizando secuencialmente, para su comodidad. Saltaré describiendo algunos de los detalles de las bibliotecas dinámicas por ahora.
Si eres un programador de Java, algo de lo anterior puede ser un poco confuso. Creo que .net funciona como Java, por lo que la siguiente discusión debería aplicarse a C # y los otros lenguajes .net. Java es sintácticamente un lenguaje mucho más simple que C y C ++. Carece de macros y carece de plantillas verdaderas (los genéricos son una forma muy débil de plantillas). Debido a esto, Java omite la necesidad de archivos separados de declaración (.h) y definición (.c). También puede incrustar toda la información relevante en el archivo objeto (.class para Java). Esto lo hace para que tanto el compilador como el enlazador puedan usar los archivos .class directamente.
Otros consejos
El problema fue de hecho con mis rutas de inclusión. Aquí está el comando relevante:
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"
También, para el enlazador, solo " PhysXLoader " era necesario (igual que Windows). Por lo tanto, tengo:
g++ -o"PhysXSetupTest" ./main.o -lglut -lPhysXLoader
Durante la instalación recibí el siguiente error *
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:
* Así que reinstalé * libphysx-2.8.1_4_i386.deb *
sudo dpkg -i libphysx-2.8.1_4_i386.deb
