Skip to content
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

Closed
JoeRosselli opened this issue Jul 3, 2024 · 3 comments
Closed

Static build of PhysX has no working linking order #662

JoeRosselli opened this issue Jul 3, 2024 · 3 comments
Assignees

Comments

@JoeRosselli
Copy link

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:

/usr/bin/ld: /.../PhysX-5.4.0/physx/install/linux/PhysX/bin/linux.clang/checked/libPhysXPvdSDK_static_64.a(PxPvdImpl.cpp.o): in function physx::pvdsdk::PvdImpl::~PvdImpl(): 
/.../PhysX-5.4.0/physx/source/pvd/src/PxPvdImpl.cpp:108:(.text._ZN5physx6pvdsdk7PvdImplD2Ev+0x38): undefined reference to PxSetPhysXGpuProfilerCallback

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:

`/usr/bin/ld: /.../PhysX-5.4.0/physx/install/linux/PhysX/bin/linux.clang/checked/libPhysX_static_64.a(NpPvdSceneClient.cpp.o): in function physx::Vd::PvdSceneClient::onPvdConnected():
/.../PhysX-5.4.0/physx/source/physx/src/NpPvdSceneClient.cpp:325:
(.text._ZN5physx2Vd14PvdSceneClient14onPvdConnectedEv+0x28): undefined reference to physx::pvdsdk::PvdDataStream::create(physx::PxPvd*)

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?

@phoenixfirestone
Copy link

I had the same problem. Here is my linking order in my cmake file:

target_link_libraries(test PUBLIC libPhysXExtensions_static_64.a)
target_link_libraries(test PUBLIC libPhysXCooking_static_64.a)
target_link_libraries(test PUBLIC libPhysX_static_64.a)
target_link_libraries(test PUBLIC libPhysXPvdSDK_static_64.a)
target_link_libraries(test PUBLIC libPhysX_static_64.a)
target_link_libraries(test PUBLIC libPhysXCharacterKinematic_static_64.a)
target_link_libraries(test PUBLIC libPhysXCommon_static_64.a)
target_link_libraries(test PUBLIC libPhysXFoundation_static_64.a)
target_link_libraries(test PUBLIC libPhysXVehicle2_static_64.a)
target_link_libraries(test PUBLIC libPhysXVehicle_static_64.a)
target_link_libraries(test PUBLIC libSnippetRender_static_64.a)
target_link_libraries(test PUBLIC libSnippetUtils_static_64.a)
target_link_libraries(test PUBLIC dl)
target_link_libraries(test PUBLIC pthread)

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.

@ayoub-belarbi
Copy link
Contributor

ayoub-belarbi commented Nov 8, 2024

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 -Wl,--start-group and -Wl,--end-group around your PhysX libraries. This tells the linker to process them as a group, looping through until all symbols are resolved.

There are two ways to do this in CMake:

  • Using target_link_libraries: You can add -Wl,--start-group and -Wl,--end-group directly in target_link_libraries to wrap the PhysX libraries, enforcing the right order and handling any circular dependencies.
  • Using target_link_options: Alternatively, if you want to keep the flags separate, you can use target_link_options to pass -Wl,--start-group and -Wl,--end-group while listing the libraries in target_link_libraries. I personally didn't try it but it should work.

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.

@ayoub-belarbi
Copy link
Contributor

ayoub-belarbi commented Nov 8, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants