Not able to use std math

[Fewnity]

Hello, I'm trying to use C++ math functions like std::round. But it's not working , I'm getting error: 'std::round' has not been declared. I checked the math.h and I saw _GLIBCXX_USE_C99_MATH_TR1 and _GLIBCXX_USE_C99_MATH. So I tried to add those flags and now I'm getting new error like: /usr/local/ps3dev/ppu/powerpc64-ps3-elf/include/c++/7.2.0/cmath:1164:11: error: '::log2l' has not been declared

How can I fix this? Thanks!

[zeldin]

std::round is C++23. Just use round (without std:: prefix) instead.

[Fewnity]

C++23? Then why std::round is defined in math.h in powerpc64-ps3-elf/include/c++/7.2.0/? I'm using std::round in older version than c++23 it should works

[zeldin]

gcc likes to throw non-standard stuff in. Sometimes they become standard after a while. :-) Also, math.h is the wrong file to include in C++, you should use <cmath>.

[Fewnity]

Oh I see... So is it the same for std::filesystem and std::to_string? Those are not found too. I saw the pullrequest about updating gcc, do you think this pr may fix my problems?

[zeldin]

std::filesystem is C++17, but g++ only supports it from version 8.1 (see https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017). So for that the gcc version bump may help, yes.

std::to_string OTOH is C++11, which is supposed to be fully supported in 7.2. It looks like maybe it didn't like the stdio facilities of newlib during config? The _GLIBCXX_USE_whatever defines are not something you can set yourself (like GNU_SOURCE), but are set when libstdc++ is compiled based on what it can use from libc etc.

[Fewnity]

Okay I'm trying to compile the toolchain with the PR. Will see if filesystem call are found after this.

Do you have an idea how to fix the to_string? I really have no idea how to fix this kind of problem ahah

[zeldin]

Well, using a newer newlib might help; the one we use now is 12 years old so there might be new stuff that libstdc++ can use in newer versions.

[Fewnity]

Oh I see. Can I expect an update of the ps3 newlib version in the future?

[zeldin]

Honestly I wouldn't get my hopes up for someone to spend work on something which might fix a minor issue they're not affected by themselves, and which may introduce regressions. If you do the work and there are no regressions, I expect it could be merged.

Personally I'd just use sprintf or make my own to_string using std::stringstream:

#include <sstream>

template <typename T> std::string to_string( T value )
{
  std::stringstream ss;
  ss << value;
  return ss.str();
}

:smile_cat:

[Fewnity]

Thanks for the code, but unfortunately I can't go any further, I was going to add ps3 support to a game engine, but if I have to modify the engine and libraries to correct the missing functions, it's going to be hard and long ahah 😅

[miigotu]

Thanks for the code, but unfortunately I can't go any further, I was going to add ps3 support to a game engine, but if I have to modify the engine and libraries to correct the missing functions, it's going to be hard and long ahah 😅

Nothing worth doing is ever not "hard and long" ahaha

Honestly, porting a newer newlib would be your first best step, and the least pain, than trying to backport a set of libraries/engines built on a newer standard.

[Fewnity]

Honestly, porting a newer newlib would be your first best step, and the least pain, than trying to backport a set of libraries/engines built on a newer standard.

Yeah you're probably right, but it's just that I've never modified an sdk and I think that it's not just by copying the latest version of newlib that it will work, there will be modifications to make on it 🤔

[zeldin]

there will be modifications to make on it

Yes. Or at the very least the modifications we have already done may need updating to work with the new version. Updating newlib is a bit more hassle than updating gcc because PSL1GHT interacts directly with it to inject platform specific functionality.