tags:

views:

976

answers:

2

Hello.

I am having a problem getting my project to link with the PhysX libraries on my 64-bit machine. It compiles perfectly fine. I've used the exact same settings as on my 32-bit machine (with the exception of some debugging flags), which links perfectly fine. Here is the build output:

g++ -L/usr/lib/PhysX/v2.8.1 -L/usr/lib -o"PhysXTest" ./main.o -lPhysXLoader -lglut

/usr/bin/ld: skipping incompatible /usr/lib/libPhysXLoader.so when searching for -lPhysXLoader

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/libPhysXLoader.so when searching for -lPhysXLoader

usr/bin/ld: skipping incompatible /usr/lib/../lib/libPhysXLoader.so when searching for -lPhysXLoader

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../libPhysXLoader.so when searching for -lPhysXLoader

/usr/bin/ld: skipping incompatible /usr/bin/../lib/libPhysXLoader.so when searching for -lPhysXLoader

/usr/bin/ld: skipping incompatible /usr/lib64/libPhysXLoader.so when searching for -lPhysXLoader

/usr/bin/ld: skipping incompatible /usr/lib/libPhysXLoader.so when searching for -lPhysXLoader

/usr/bin/ld: cannot find -lPhysXLoader

Also, if it's of any consequence, I have already set up symbolic links to usr/lib. Does anyone know what's going on? Please let me know if you need any more detail. As always, thanks in advance.

+1  A: 

It looks like your PhysiX sharedobject is compiled in 32bit. You can't link a 32bit .so to a 64bit application, the elf are different. Have you downloaded the 64bit version of the library? I'm not even sure if PhysX has 64bit support though. It didn't last time I looked but that was almost 2 years ago by now.

Edit: PhysX uses some serious array processing and assembly and other very low-level memory tricks, that depend on 32bit architecture. It would take a great amount of work to get it to run in 64bit. Now since they aim at console game makers (their true PAYING customers), and no console is 64bit yet and it'll probably be a while before they release a 64bit version, so you won't be able to link, and even if you did trick the compiler to link them, it would core dump right away

Robert Gould
Yeah, there is no 64-bit library at the moment. I had to do something to force it to install under 64-bit. I was under the impression that it would still be compatible. Perhaps I was mislead.
Scott
PhysX uses some serious array processing and assembly and other very low-level memory tricks, that depend on 32bit architecture. It would take a great amount of work to get it to run in 64bit. Now since they aim at console game makers (their true PAYING customers), and no console is 64bit yet...
Robert Gould
... it'll probably be a while before they release a 64bit version, so you won't be able to link, and even if you did trick the compiler to link them, it would core dump right away :(
Robert Gould
Ah! Apparently it is possible! You have to use the "-m32" flag. People have actually gotten it to work. However, now it is not linking glut properly. The 64-bit libraries for glut no longer seem to work. I need to get it to link the 32-bit ones. I've specified /usr/lib32 in the search path...
Scott
...but it's still looking in usr/lib. I will post an answer when I get it to link (assuming that I do).
Scott
you might have to change the order of appearance in the environment for lib and lib32
Robert Gould
+3  A: 

As Robert Gould said, you can not link together 32 and 64-bit objects or shared libraries; they are simply not link-compatible.

Since you only have 32-bit PhysX, you must compile all other code that will be linked into the executable (main.o in your example) in 32-bit mode (by using the -m32 gcc flag), and install 32-bit versions of all other libraries (glut, libGL, libX11, libc, etc.).

RedHat makes this easy -- they provide 32 and 64-bit packages for everything, and separate them into /usr/lib32 and /usr/lib64 ...

AFAICT, Ubuntu does not: both amd64 and i386 packages contain /usr/lib/libglut.so.3.8.0. You would need to download 32-bit versions of everything, and install them into /usr/lib32 instead of /usr/lib "by hand".

Employed Russian
thanks for clearing that up, I don't use Unbuntu myself so I wasn't aware they didn't ship both
Robert Gould