std::fmax and std::fmin not member of 'std'

[kas1e]

Another one of the same set of errors, this time fmin and fmax. Happens the same and for newlib and for clib2. Test case:

#include <iostream>
#include <cmath>

int main()
{
    std::cout << "fmin(2,1)    = " << std::fmin(2,1) << '\n'
              << "fmax(2,1)    = " << std::fmax(2,1) << '\n'
}

result:

$ ppc-amigaos-g++ test.cpp -o test
test.cpp: In function ‘int main()’:
test.cpp:6:44: error: ‘fmin’ is not a member of ‘std’
     std::cout << "fmin(2,1)    = " << std::fmin(2,1) << '\n'
                                            ^~~~
test.cpp:6:44: note: suggested alternative: ‘min’
     std::cout << "fmin(2,1)    = " << std::fmin(2,1) << '\n'
                                            ^~~~
                                            min
test.cpp:7:44: error: ‘fmax’ is not a member of ‘std’
               << "fmax(2,1)    = " << std::fmax(2,1) << '\n'
                                            ^~~~
test.cpp:7:44: note: suggested alternative: ‘max’
               << "fmax(2,1)    = " << std::fmax(2,1) << '\n'
                                            ^~~~
                                            max

[sba1]

Like any similar error this is most likely the result of the respective c libraries not implementing these functions. Please check, if these functions exist within the library. Only if they exists, this is a valid place to report the bug, otherwise you should file an issue to the the official clib or newlib repositories.

[kas1e]

To make all those functions work, all that I need is just remove "std::", and then all fine. The issue mostly that general code didn't compile out of the box and need all the time remove "std::".

[kas1e]

I think that it all just a matter of fixing something in the compiling times of GCC. Like enable some flag or made some declaration somewhere, etc. As all those functions implemented and work, just not when you have std:: at the beginning. Which means that it probably right to report things here?

[sba1]

It depends ;) I recall that even if some functions are present a similar function may be missing and thus the configure stage of libstdc++ may disable a whole family of functions (at least it was not very fine-grained in the past). It would be nice to research on that and then to implement the missing functions in the clibs if there are any. I believe that a C11 library set is needed for current versions of libstdc++ and neither clib2 nor newlib fulfils this, if I'm not mistaken. Another case that previously happend was that certain functions were available in the clibs but were not available when compiling with a standard C11 mode (while those functions are part of the standard in C11 but not of pre C11; again, I don't remember details). But generally, the patches should be kept minimal here (there are already some patches like this in this project, maybe they are wrong or causing issues). Thus I think this may be a good stratagy:

1. Analyze the configure stage of libstdc++
2. Identify which changes are required to adjust the clibs so the libstdc++ configure stage improves.
3. Depending on the outcome, modifiy the clibs or submit patches here.

Given the fact that libstc++ does not fail on other targets, my bet is that most fixes can be applied to the clibs alone. Of couse, it is great to have examples that fail here. But where the ultimative fix is applied needs to be sorted out though.

[sodero]

Indeed, autotools can create confusing butterfly effects. I looked into the details of how libstd++ is configured today. The plan is to do a fully stubbed (as in full (almost at least) POSIX support plus some GNU externsions) clib2 and see what the outcome will be. Hopefully something like this: When building things with a stubbed clib2 you'll get warnings instead of errors. And during runtime (if you get that far) you'll get warnings when a stubbed block is used. The runtime warnings can be used to raise the priority of implementing that specific function. And last but not least, by lying to autotools, configure will probably draw more optimistic conclusions which will lead to less working features being hidden like above.

[afxgroup]

i suppose we need to fork and mantain a new clib2 version because newlib is a no-exit library. And try to use clib2 for all modern software. i see no other way to fix all our Clib problems

[sodero]

Yes, I don't understand why the OS4 newlib is kept in-house. They could get work done for free if they would publish it. clib2 is the most reasonable solution as it is now IMO.

[kas1e]

@afxgroup
@sodero

The only problem , that it near to impossible to recompile all 3d party libs over clib2 now. There just too many in newlib only form, and there was just too many libs which can be compiled only over newlib (Because of any reassons).

For example, all the deps for Odyssey are newlib based, and whole odyssey too. Is there anyone willing to spend a HUGE task to report it to clib2 ? Sure not. And the same for everything else.

The only way is to annoy ppls at hyperion to make newlib opensource.

[afxgroup]

Well, you can continue to use newlib for your projects. But we can't fix or modify it. So if you need a fix you have to wait something on dev side that fix it and release it to the public. And we know how it works. With clib2 this problem doesn't exists. We should recompile all packages also for clib2. i don't think this is a huge effort. at least for commons packages

[kas1e]

@afxgroup

We should recompile all packages also for clib2. I don't think this is a huge effort. at least for commons packages

I tried before and tired very fast. Clib2 missing quite much as well in comparison with newlib. I mean just some basic functionality while having some other things which newlib didn't have. I didn't have a list right now, but I remember how it was when I was in choosing what to use.

Besides, I don't see anyone updating clib2 as well :) We can have the same trap here called "Waiting years for fixes/adding functionality which already in newlib".

ps. I asked Hyperioin's management about what they think about opening newlib, let's see what they answer. Maybe today things can be a bit more logical from their side when there is a new manager.

[afxgroup]

i've cloned clib2 locally and i've added some missing functions. it is more more more more simply to manage instead of newlib (i've added some functions are now in newlib and it is a pain..)

[sodero]

Please open a PR in clib2. It would be great if we could fill the gaps there.

[afxgroup]

i've added my clib2 version here:

https://github.com/afxgroup/clib2

It has some implementation and some basic IPV6 defines too.
I've compiled GnuTLS without any problem and along its compilation i've added functions to clib2 like inet_pton or inet_ntop, poll and some others. Plus i've added some missing defines to include files.
Feel free to test it.. of course it can crash but at least you can patch it since it is free

[kas1e]

@afxgroup
Sadly it is uploaded already with the changes, so we can't see what was changed exactly, and we can't rollback if things go bad. Is it not possible to branch original clib2, and commit by commit add your changes?

[afxgroup]

No because i didn't fork the project originally. Just cloned. So it is hard to create a fork. But you can simply make a "diff". There are no many files changed. However next changes will have the file changed

[kas1e]

Sure I can, but to make it all of use for others, we IMHO need to make a diff and then clone the repo, then make a new one, and then update "diff" changes. Yes, still suck, because many at once, but still other ones will see what exactly was changed and where, so to be sure nothing broken, or at least later can re-check if changes cause new issues.

Because as it now, no one will see for real what changes and will fear to work on top of that.

[capehill]

It shouldn't be too hard.

1. Fork the original
2. Copy changed files over
3. Create atomic commits (git add -p can help)
4. Open pull request against original

[afxgroup]

Here it is. However i'll continue to work on my version. I don't want to mix my ugly code with Olaf one :D

https://github.com/afxgroup/clib2-1

[kas1e]

from newlib's side everything about "not a member of std::" was fixed in the new beta of newlib 53.69 and adtools recompiled with new newlib's headers.