Instalando e vinculando PhysX bibliotecas no Debian Linux
https://stackoverflow.com/questions/415279
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Eu estou tentando obter PhysX trabalhar usando o Ubuntu.
Em primeiro lugar, eu baixei o SDK aqui:
Em seguida, eu extraiu os arquivos e instalado cada pacote com:
dpkg -i filename.deb
Isto dá-me os seguintes arquivos localizados em /usr/lib/PhysX/v2.8.1:
- libNxCharacter.so
- libNxCooking.so
- libPhysXCore.so
- libNxCharacter.so.1
- libNxCooking.so.1
- libPhysXCore.so.1
Em seguida, eu criei links simbólicos para / 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
Agora, usando Eclipse, eu tenha especificado as seguintes bibliotecas (-l):
- libNxCharacter.so.1
- libNxCooking.so.1
- libPhysXCore.so.1
E os seguintes caminhos de pesquisa apenas no caso (-L):
- /usr/lib/PhysX/v2.8.1
- / usr / lib
Além disso, como Gerald Kaszuba sugeriu, eu adicionei o seguinte incluir caminhos (-I):
- /usr/lib/PhysX/v2.8.1
- / usr / lib
Então, eu tentei compilar o código a seguir:
#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;
}
O primeiro erro que recebo é:
NxPhysics.h: Nenhum tal lima ou diretório
O que me diz que o projeto, obviamente, não está ligando corretamente. Alguém pode me dizer o que eu tenho feito de errado, ou o que mais eu preciso fazer para obter meu projeto para compilar? Eu estou usando o ++ Compiler GCC C. Agradecemos antecipadamente!
Solução
Parece que você está confundindo arquivos de cabeçalho com arquivos de biblioteca. NxPhysics.h é um arquivo de cabeçalho do código fonte. arquivos de cabeçalho são necessárias quando compilar o código fonte (não ao ligar). Ele provavelmente está localizado em um lugar como / usr / include ou /usr/include/PhysX/v2.8.1, ou similar. Encontrar a localização real deste arquivo e certifique-se de usar a opção -I para dizer ao compilador onde ele está, como Gerald Kaszuba sugere.
As bibliotecas são necessários quando liga os arquivos de objeto compilados (e não ao compilar). Você vai precisar para lidar com isso mais tarde com as opções -l e -l.
Nota: dependendo de como você chama gcc, você pode ter que compilar e, em seguida, ligando com uma única chamada, mas nos bastidores ele ainda faz um passo de compilação, em seguida, um passo ligação
.EDIT: explicação extra adicionado ...
Quando a construção de um binário usando o compilador C / C ++, o compilador lê o código fonte (.c ou .cpp arquivos). Ao lê-lo, há declarações frequentemente # include que são usados ??para ler arquivos .h. As instruções # include dar os nomes de arquivos que devem ser carregados. Esses arquivos exatos devem existir no caminho de inclusão. No seu caso, um arquivo com o nome exato "NxPhysics.h" deve ser encontrada em algum lugar no caminho de inclusão. Normalmente, / usr / include está no caminho por padrão, e assim é o diretório atual. Se os cabeçalhos estão em outro lugar, como um subdiretório de / usr / include, então você sempre precisa dizer explicitamente o compilador onde procurar usando as opções de linha de comando -I (ou às vezes com variáveis ??de ambiente ou de outros métodos de configuração do sistema).
A .h arquivo de cabeçalho geralmente inclui declarações de dados estrutura, definições de funções inline, de função e de classe declarações e macros #define. Quando a compilação é feita, um arquivo objeto .o é criado. O compilador não sabe sobre .so ou .a bibliotecas e não pode usá-los de qualquer forma, além de incorporar um pouco de informação auxiliar para o vinculador. Note que o compilador também incorpora algumas informações "header" nos arquivos de objeto. Eu coloquei "cabeçalho" entre aspas porque a informação corresponde apenas a cerca do que pode ou não pode ser encontrada nos arquivos .h. Ele inclui uma representação binária de todas as declarações exportados. Não macros são encontrados lá. Acredito que funções inline são omitidos, bem como (embora eu poderia estar errado lá).
Depois de todos os arquivos .o existir, é hora de outro programa para assumir: o vinculador. O vinculador não sabe nada de arquivos de código-fonte ou arquivos de cabeçalho .h. Ele só se preocupa com bibliotecas binários e arquivos objeto. Você dar-lhe uma coleção de bibliotecas e arquivos objeto. Em suas "cabeçalhos" que lista as coisas (tipos de dados, funções, etc.) eles definem e as coisas que eles precisam de alguém para definir. O vinculador, em seguida, combina-se pedidos de definições de um módulo com definições reais para outros módulos. Ele verifica para se certificar de que não existem múltiplas definições conflitantes, e se a construção de um executável, ele garante que todos os pedidos de definições são cumpridas.
Existem algumas ressalvas notáveis ??para a descrição acima. Primeiro, é possível chamar gcc uma vez e começar a fazer as duas coisas compilar e ligar, por exemplo.
gcc hello.c -o hello
vai hello.c primeira compilação para a memória ou para um arquivo temporário, em seguida, ele irá ligar com as bibliotecas padrão e escrever o executável Olá. Mesmo que seja apenas uma chamada para o gcc, as duas etapas ainda estão sendo realizadas sequencialmente, como uma conveniência para você. Eu vou pular descrevendo alguns dos detalhes de bibliotecas dinâmicas para agora.
Se você é um programador Java, em seguida, alguns dos acima pode ser um pouco confuso. Acredito que .net funciona como Java, de modo que a discussão a seguir deve aplicar-se a C # e outras linguagens .NET. Java é sintaticamente uma linguagem muito mais simples do que C e C ++. Ela carece de macros e carece de verdadeiros modelos (os genéricos são muito weak forma de moldes). Devido a isso, Java ignora a necessidade de declaração separada (.h) e arquivos de definição (.c). Ele também é capaz de incorporar todas as informações relevantes no arquivo do objeto (.class para Java). Isso faz com que o compilador eo vinculador pode usar os arquivos .class diretamente.
Outras dicas
O problema era realmente com meus incluir caminhos. Aqui está o 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"
Além disso, para o vinculador, apenas "PhysXLoader" era necessária (o mesmo que Windows). Assim, eu tenho:
g++ -o"PhysXSetupTest" ./main.o -lglut -lPhysXLoader
Durante a instalação eu tenho o seguinte erro *
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:
* Então eu reinstalado * libphysx-2.8.1_4_i386.deb *
sudo dpkg -i libphysx-2.8.1_4_i386.deb
