DanielChappuis / reactphysics3d

Open source C++ physics engine library in 3D
http://www.reactphysics3d.com
zlib License
1.54k stars 224 forks source link

Build failing - Missing include in configuration.h #370

Closed JoeRosselli closed 8 months ago

JoeRosselli commented 9 months ago

Hi,

The Problem

The project fails to build for me on Ubuntu 23.10 using GCC 13.2.0 and CMake 3.27.4.

I'm doing a basic git check out, cmake, then make flow.

Sample error message:

/{redacted}/reactphysics3d/include/reactphysics3d/configuration.h:69:19: error: ‘int8_t’ in namespace ‘std’ does not name a type; did you mean ‘wint_t’?

When attempting to build it outputs hundreds/thousands of errors related to this.

The Cause/Fix

The root problem seems to be because configuration.h references various standard library type definitions (std::int8_t, std::uint8_t, etc.,) but doesn't include the header they're defined in.

All of those type definitions are defined in cstdint, and so configuration.h should be modified to include this header (https://en.cppreference.com/w/cpp/header/cstdint)

I tested locally modifying the header to include cstdint with the other system headers and all errors went away and the project built successfully without issue.

Here are the problematic lines:

https://github.com/DanielChappuis/reactphysics3d/blob/17dd22e677ed861b0d4ece0c00a7e3cb503cc2f0/include/reactphysics3d/configuration.h#L68-L75

Thanks!

JoeRosselli commented 9 months ago

I should probably also note that I'm building with cxx_std_23 compiler feature enabled.

The build failure is likely a combination of compiler + c++ version, where the latest c++ standard/compiler no longer erroneously exposes the type definitions from other system headers and now cstdint is required to be included.

DanielChappuis commented 9 months ago

Thanks for reporting this issue. This has been fixed and merged into the 'develop' branch in the this pull request. This fix will be available in the next release of the library.

DanielChappuis commented 8 months ago

This is now fixed in version v0.10.0 of the library. Thanks a lot for reporting the issue.