在Debian Linux中安装和链接PhysX库

我正在尝试使用Ubuntu让PhysX工作

首先，我在这里下载了SDK：

---

接下来，我提取了文件并安装了每个软件包，其中包括：

dpkg -i filename.deb

这为我提供了位于/usr/lib/PhysX/v2.8.1中的以下文件：

• libNxCharacter.so
• Libnx.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
• /usr/lib

此外，正如Gerald Kaszuba所建议的，我添加了以下include路径（-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;
}

#包括“nxpysics.h”
nxphysicsdk*gpphysissdk=NULL；
nxsecene*gScene=NULL；
NxVec3-gDefaultGravity（0，-9.8,0）；
void InitNx（）
{
gpphysissdk=nxcreatephysicsdk（NX_PHYSICS_SDK_版本）；
如果（！gpyssdk）
{
std:：cout看起来您混淆了头文件和库文件。nxpysics.h是源代码头文件。编译源代码时需要头文件（而不是链接时）。它可能位于/usr/include或/usr/include/PhysX/v2.8.1或类似位置。如Gerald Kaszuba所建议的，找到此文件的真实位置，并确保使用-I选项告诉编译器它在哪里

链接已编译的对象文件时（而不是编译时）需要这些库

注意：根据您调用gcc的方式，您可以让它进行编译，然后通过单个调用进行链接，但在幕后，它仍然执行编译步骤，然后是链接步骤


编辑：添加了额外解释

使用C/C++编译器生成二进制文件时，编译器读取源代码（.C或.cpp文件）。在读取时，经常会有用于读取.h文件的#include语句。这些#include语句提供必须加载的文件的名称。这些确切的文件必须存在于include路径中。在您的情况下，一个确切名称为“nxpysics.h”的文件必须在include路径中的某个位置找到。通常，/usr/include默认位于路径中，当前目录也是如此。如果头位于其他位置，例如/usr/include的子目录，则始终需要使用-I命令行开关显式地告诉编译器在何处查找（有时使用环境变量或其他系统配置方法）

.h头文件通常包括数据结构声明、内联函数定义、函数和类声明以及#定义宏。编译完成后，将创建一个.o对象文件。编译器不知道.so或.A库，不能以任何方式使用它们，只能嵌入一点辅助信息n表示链接器。请注意，编译器还将一些“头”信息嵌入到对象文件中。我将“头”放在在引号中，因为信息仅大致对应于.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 for Java）中。这样，编译器和链接器都可以直接使用.class文件。
问题确实出在我的包含路径上。以下是相关命令：

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

安装时，我得到了以下错误
*

*
所以我重新安装了*libphysx-2.8.1_4_i386.deb*

sudo dpkg -i libphysx-2.8.1_4_i386.deb 

你是对的！我没有注意到，但软件包确实将文件放在了/usr/include中。但是，我认为.h文件可能存在于某个库文件中，这是错误的吗？此页：声明一个.so文件…（续）…con
sudo dpkg -i libphysx-2.8.1_4_i386.deb