Установка и компоновка библиотек PhysX в Debian Linux - PullRequest
2 голосов
/ 06 января 2009

Я пытаюсь заставить PhysX работать с Ubuntu.

Сначала я скачал SDK здесь:


Затем я извлек файлы и установил каждый пакет с помощью:

dpkg -i filename.deb

Это дает мне следующие файлы, расположенные в /usr/lib/PhysX/v2.8.1:

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

Далее я создал символические ссылки на / 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

Теперь, используя Eclipse, я указал следующие библиотеки (-l):

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

И следующие пути поиска на всякий случай (-L):

  • / USR / Lib / PhysX / v2.8.1

Также, как предложил Джеральд Кашуба, я добавил следующие пути включения (-I):

  • / USR / Lib / PhysX / v2.8.1
  • / USR / Lib

Затем я попытался скомпилировать следующий код:

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

Первая ошибка, которую я получаю:

NxPhysics.h: нет такого файла или каталога

Что говорит мне о том, что проект явно не связывается должным образом. Может кто-нибудь сказать мне, что я сделал неправильно, или что еще мне нужно сделать, чтобы мой проект компилировался? Я использую компилятор GCC C ++. Заранее спасибо!

Ответы [ 3 ]

2 голосов
/ 06 января 2009

Похоже, вы путаете заголовочные файлы с библиотечными файлами. NxPhysics.h - файл заголовка исходного кода. Заголовочные файлы необходимы при компиляции исходного кода (не при компоновке). Вероятно, он находится в таком месте, как / usr / include или /usr/include/PhysX/v2.8.1, или похожем. Найдите реальное местоположение этого файла и убедитесь, что вы используете опцию -I, чтобы сообщить компилятору, где он находится, как предлагает Джеральд Кашуба.

Библиотеки необходимы при компоновке скомпилированных объектных файлов (а не при компиляции). Вам нужно будет разобраться с этим позже с опциями -L и -l.

Примечание: в зависимости от того, как вы вызываете gcc, вы можете сделать так, чтобы он компилировал и затем связывал с одним вызовом, но за кулисами он по-прежнему выполняет этап компиляции, а затем шаг ссылки.


РЕДАКТИРОВАТЬ: Добавлено дополнительное объяснение ...

При сборке двоичного файла с использованием компилятора C / C ++ компилятор считывает исходный код (файлы .c или .cpp). Во время чтения часто встречаются операторы #include, которые используются для чтения файлов .h. Операторы #include дают имена файлов, которые должны быть загружены. Эти точные файлы должны существовать в пути включения. В вашем случае файл с точным именем «NxPhysics.h» должен быть найден где-то в пути включения. Как правило, / usr / include находится в пути по умолчанию, как и текущий каталог. Если заголовки находятся где-то еще, например в подкаталоге / usr / include, вам всегда нужно явно указывать компилятору, где искать, используя ключи командной строки -I (или иногда с переменными среды или другими методами конфигурации системы).

Файл заголовка .h обычно включает объявления структуры данных, определения встроенных функций, объявления функций и классов и макросы #define. Когда компиляция завершена, создается объектный файл .o. Компилятор не знает о библиотеках .so или .a и не может использовать их каким-либо образом, кроме как для добавления небольшого количества вспомогательной информации для компоновщика. Обратите внимание, что компилятор также встраивает некоторую информацию «заголовка» в объектные файлы. Я помещаю «заголовок» в кавычки, потому что информация только приблизительно соответствует тому, что может или не может быть найдено в .h файлах. Он включает в себя двоичное представление всех экспортируемых объявлений. Макросы там не найдены. Я считаю, что встроенные функции также опущены (хотя я могу ошибаться там).

Как только все .o файлы существуют, пришло время взять на себя другую программу: компоновщик. Компоновщик ничего не знает о файлах исходного кода или файлах заголовков .h. Он заботится только о двоичных библиотеках и объектных файлах. Вы даете ему коллекцию библиотек и объектных файлов. В своих «заголовках» они перечисляют, какие вещи (типы данных, функции и т. Д.) Они определяют и какие вещи им нужно, чтобы кто-то еще определил. Затем компоновщик сопоставляет запросы на определения из одного модуля с фактическими определениями для других модулей. Он проверяет, не существует ли нескольких конфликтующих определений, и, если строит исполняемый файл, он проверяет выполнение всех запросов на определения.

Есть несколько заметных предостережений в приведенном выше описании. Во-первых, можно один раз вызвать gcc и заставить его выполнять как компиляцию, так и компоновку, например

gcc hello.c -o hello

сначала скомпилирует hello.c в память или во временный файл, затем свяжется со стандартными библиотеками и запишет исполняемый файл hello. Хотя это только один вызов gcc, оба шага все еще выполняются последовательно, для вашего удобства. Сейчас я пропущу описание некоторых деталей динамических библиотек.

Если вы программист на Java, то некоторые из вышеперечисленных могут быть немного запутанными. Я считаю, что .net работает как Java, поэтому следующее обсуждение должно относиться к C # и другим языкам .net. Синтаксически Java намного проще, чем C и C ++. В нем отсутствуют макросы и отсутствуют настоящие шаблоны (дженерики - очень слабая форма шаблонов). Из-за этого Java пропускает необходимость в отдельных файлах объявлений (.h) и определений (.c). Он также может встраивать всю необходимую информацию в объектный файл (.class для Java). Это делает так, что и компилятор, и компоновщик могут напрямую использовать файлы .class.

0 голосов
/ 22 февраля 2011

При установке я получил следующую ошибку *

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:

* Поэтому я переустановил * libphysx-2.8.1_4_i386.deb *

sudo dpkg -i libphysx-2.8.1_4_i386.deb 
0 голосов
/ 06 января 2009

Проблема действительно была с моими путями включения. Вот соответствующая команда:

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"

Кроме того, для компоновщика был необходим только «PhysXLoader» (так же, как Windows). Таким образом, у меня есть:

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