I am trying to get PhysX working using Ubuntu.
First, I downloaded the SDK here:
Next, I extracted the files and installed each package with:
dpkg -i filename.deb This gives me the following files located in /usr/lib/PhysX/v2.8.1:
- libNxCharacter.so
- libNxCooking.so
- libPhysXCore.so
- libNxCharacter.so.1
- libNxCooking.so.1
- libPhysXCore.so.1
Next, I created symbolic links to /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 Now, using Eclipse, I have specified the following libraries (-l):
- libNxCharacter.so.1
- libNxCooking.so.1
- libPhysXCore.so.1
And the following search paths just in case (-L):
- /usr/lib/PhysX/v2.8.1
- /usr/lib
Also, as Gerald Kaszuba suggested, I added the following include paths (-I):
- /usr/lib/PhysX/v2.8.1
- /usr/lib
Then, I attempted to compile the following code:
#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; } The first error I get is:
NxPhysics.h: No such file or directory
Which tells me that the project is obviously not linking properly. Can anyone tell me what I have done wrong, or what else I need to do to get my project to compile? I am using the GCC C++ Compiler. Thanks in advance!
It looks like you’re confusing header files with library files. NxPhysics.h is a source code header file. Header files are needed when compiling source code (not when linking). It’s probably located in a place like /usr/include or /usr/include/PhysX/v2.8.1, or similar. Find the real location of this file and make sure you use the -I option to tell the compiler where it is, as Gerald Kaszuba suggests.
The libraries are needed when linking the compiled object files (and not when compiling). You’ll need to deal with this later with the -L and -l options.
Note: depending on how you invoke gcc, you can have it do compiling and then linking with a single invocation, but behind the scenes it still does a compile step then a link step.
EDIT: Extra explanation added…
When building a binary using a C/C++ compiler, the compiler reads the source code (.c or .cpp files). While reading it, there are frequently #include statements that are used to read .h files. The #include statements give the names of files that must be loaded. Those exact files must exist in the include path. In your case, a file with the exact name ‘NxPhysics.h’ must be found somewhere in the include path. Typically, /usr/include is in the path by default, and so is the current directory. If the headers are somewhere else such as a subdirectory of /usr/include, then you always need to explicitly tell the compiler where to look using the -I command-line switches (or sometimes with environment variables or other system configuration methods).
A .h header file typically includes data structure declarations, inline function definitions, function and class declarations, and #define macros. When the compilation is done, a .o object file is created. The compiler does not know about .so or .a libraries and cannot use them in any way, other than to embed a little bit of helper information for the linker. Note that the compiler also embeds some ‘header’ information in the object files. I put ‘header’ in quotes because the information only roughly corresponds to what may or may not be found in the .h files. It includes a binary representation of all exported declarations. No macros are found there. I believe that inline functions are omitted as well (though I could be wrong there).
Once all of the .o files exist, it is time for another program to take over: the linker. The linker knows nothing of source code files or .h header files. It only cares about binary libraries and object files. You give it a collection of libraries and object files. In their ‘headers’ they list what things (data types, functions, etc.) they define and what things they need someone else to define. The linker then matches up requests for definitions from one module with actual definitions for other modules. It checks to make sure there aren’t multiple conflicting definitions, and if building an executable, it makes sure that all requests for definitions are fulfilled.
There are some notable caveats to the above description. First, it is possible to call gcc once and get it to do both compiling and linking, e.g.
will first compile hello.c to memory or to a temporary file, then it will link against the standard libraries and write out the hello executable. Even though it’s only one call to gcc, both steps are still being performed sequentially, as a convenience to you. I’ll skip describing some of the details of dynamic libraries for now.
If you’re a Java programmer, then some of the above might be a little confusing. I believe that .net works like Java, so the following discussion should apply to C# and the other .net languages. Java is syntactically a much simpler language than C and C++. It lacks macros and it lacks true templates (generics are a very weak form of templates). Because of this, Java skips the need for separate declaration (.h) and definition (.c) files. It is also able to embed all the relevant information in the object file (.class for Java). This makes it so that both the compiler and the linker can use the .class files directly.