-
Notifications
You must be signed in to change notification settings - Fork 807
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Static build of PhysX has no working linking order #662
Comments
I had the same problem. Here is my linking order in my cmake file: target_link_libraries(test PUBLIC libPhysXExtensions_static_64.a) Note that i added target_link_libraries(test PUBLIC libPhysX_static_64.a) twice because it seemed that libPhysX_static_64.a and libPhysXPvdSDK_static_64.a referred to each other. |
Hello! Linking issues with static libraries can be challenging, especially since the Linux linker is order-dependent. The main problem here is that the Linux linker requires libraries to be listed in a specific order to resolve dependencies, and with static libraries, it doesn’t loop back automatically. So, when there are circular dependencies, the linker requires a bit of extra guidance to ensure all dependencies are fully resolved. One fix is to use the linker flags There are two ways to do this in CMake:
Both approaches should get the linker to recognize the dependencies without running into unresolved symbols. Hope this helps! Let me know if you need more clarification. |
Some additional links/resources:
Closing now, if you still face issues, please reopen 😄 |
Hi,
When building PhysX 5.4.0 on Linux/clang with the PX_GENERATE_STATIC_LIBRARIES cmake flag set to True, it correctly builds/installs all static libraries (except for Gpu and PVDRuntime outputs which it outputs as dynamic libraries).
However, when attempting to manually link against these libraries in a consumer project, there's no linker order which doesn't result in undefined definitions in one way or another.
In particular, at the moment I'm wrestling with a circular dependency where if I link against PhysX before PhysXPvdSDK, I get a handful of linker errors, one of which being the PvdSDK project having an unresolved definition from PhysX:
However, if I switch the linking order of those two dependencies, to resolve the PvdSDK dependency, I then get different linking errors where PhysX now has undefined dependencies on PvdSDK:
The order in which I'm currently trying to link the libraries:
PhysXCharacterKinematic PhysXCooking PhysXExtensions PhysX PhysXPvdSDK PhysXCommon PhysXFoundation
I referenced this issue, #53 , which states that the order should be:
PhysX PhysXExtensions PhysXCharacterKinematic PhysXCooking PhysXFoundation PhysXVehicle PhysXPvdSDK
That spawns a hundred times more linker errors about undefined definitions.
I referenced this issue: https://forums.developer.nvidia.com/t/linking-physx-in-cmake-project/78664 , which states that the order should be something like:
PhysXExtensions PhysX PhysXPvdSDK PhysXVehicle PhysXCharacterKinematic PhysXCooking PhysXCommon PhysXFoundation SnippetUtils
Again, that linking order spawns hundreds times more undefined definition linker errors.
No matter what order I put the various dependencies in it refuses to link. The only way I've gotten things to work in the past was with PX_GENERATE_STATIC_LIBRARIES set to false, which builds some of the libraries as dynamic, which seemed to somehow link properly, but the CMake code involved to manually import and link against that output, and install it all properly with my application was extremely ugly so I'm trying to get it working with a static build now.
I'd love to just include PhysX via CMake or via package management but both of those options are either not available or broken on Linux (NVIDIA-Omniverse/PhysX#277 , NVIDIA-Omniverse/PhysX#278).
Any advice?
The text was updated successfully, but these errors were encountered: