linux - cannot build libraries (error: 'src' is an unsafe pointer used for buffer access [-Werror,-Wunsafe-buffer-usage])

[PcChip]

Library and Version

Example: PhysX v5.3.1

Operating System

Linux (Kubuntu 23.10)

Steps to Trigger Behavior

1. clone repo
2. install clang (FYI - I didn't see this requirement documented anywhere?)
3. run ./generate_projects.sh
4. cd to compiler/linux-checked
5. run 'make'

Expected Behavior

libraries are compiled

Actual Behavior

dozens of errors such as the following:
error: unsafe buffer access [-Werror,-Wunsafe-buffer-usage]

[PcChip]

[JoeRosselli]

I also tried building physx on linux today, via vcpkg, and got interestingly similar but slightly different build errors.

I see in your errors the file DyFeatherstoneArticulation.h, whereas I'm seeing errors in DyFeatherstoneForwardDynamic.cpp

The errors I get involve stringop-overread issues, such as:

DyFeatherstoneForwardDynamic.cpp:451:68: error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ reading between 16 and 1020 bytes from a region of size 0 [-Werror=stringop-overread]
  451 |                                         invStIs.invStIs[ind][ind2] = invD[ind][ind2];

I'm assuming our issues are somewhat related as we're both building on linux on the same day and both getting compile failures related to warnings treated as errors in DyFeatherstone stuff.

For reference, my repro using vcpkg is simply:

git clone https://github.com/microsoft/vcpkg
./vcpkg/bootstrap-vcpkg.sh
./vcpkg/vcpkg install physx

Doing the above fails. It seems like debug build succeeds but release build fails?

[PcChip]

I also tried building with vcpckg but had totally different errors

I was able to get past this error by editing the following file:
/physx/source/compiler/cmake/linux/CMakeLists.txt

and changed line 30 to the following:

SET(CLANG_WARNINGS "-ferror-limit=0 -Wstrict-aliasing=2 -Weverything\

basically disabling "warnings as errors"

[ayoub-belarbi]

Thanks for reporting this. Yes for now just disable that warning using -Wno-unsafe-buffer-usage, we will try to fix this issue in the next release.
Thank you

[preist-nvidia]

@PcChip - what version of clang are you using? We list supported compiler versions here: https://github.com/NVIDIA-Omniverse/PhysX/blob/main/physx/documentation/platformreadme/linux/README_LINUX.md#required-packages-to-generate-projects

[PcChip]

@PcChip - what version of clang are you using? We list supported compiler versions here: https://github.com/NVIDIA-Omniverse/PhysX/blob/main/physx/documentation/platformreadme/linux/README_LINUX.md#required-packages-to-generate-projects

Hello, thanks for the link - I was viewing the documentation here: https://nvidia-omniverse.github.io/PhysX/physx/5.3.1/docs/BuildingWithPhysX.html#generating-projects-with-cmake

and I did not see that mentioned so I didn't even know I needed clang installed

I am using whatever version installs on Kubuntu 23.10 when typing "sudo apt install clang" , I can check and update this post when I get home

I do appreciate the responses, thank you for your time!

[ayoub-belarbi]

You are right, the platform readme here: https://github.com/NVIDIA-Omniverse/PhysX/blob/main/physx/documentation/platformreadme/linux/README_LINUX.md mentions gcc or clang which is not precise. We will fix that in the next release together with the warnings.
Thank you

[ayoub-belarbi]

Internal tracking: PX-5053

[JoeRosselli]

Hi, in the meantime, is there a workaround? I'm pretty blocked.

If I'm unable to consume PhysX via package management systems, are there directions somewhere on how to manually integrate PhysX with a cmake-based project?

I don't see any official directions other than for how to do a manual build of PhysX, which is a process that does not remotely integrate with a cross-platform cmake-based project. Are there any official examples of doing this?

Thank you

[JoeRosselli]

Can I suggest making a change such that the -Werror flag is not enabled by default in the source that's released to the public? Maybe just do that work as a one word quick fix, separate from fixing the warnings?

Even if you put in the time to fix the warnings and get things building again, there's always going to be new compiler versions in the future that will cause new warnings and then the build will be broken again.

Given that it's been many, many months that PhysX has not built successfully on Linux, it doesn't seem like there's the resources to keep on top of things and quickly support newer compiler versions, so in that case warnings=error should definitely be turned off by default so that it'll naturally at least just keep building going into the future without further work needed.

You can have whatever internal setup you want for always building with -Werror , it just isn't ideal to have it enabled by default in source that's released and built by consumers.

Also, I just wanted to clarify the scope of this problem:

• PhysX does not build on Linux using any compiler made in the last 2 years
• You can not take a dependency on PhysX from any package management solutions, as package management solutions build the source as is with no opportunity to modify the build flags
• Anything that's in package management that depends on PhysX also fails to build, as PhysX can't be compiled
• There is no automated way to fetch and build PhysX, or take a dependency on PhysX, on Linux

(Assuming I don't want to use a 3+ year old compiler as my system compiler, which I don't).