Re: MacPorts builds for 'Yosemite' and 'El Capitan' fail

[Hans Åberg]

> On 5 Feb 2023, at 13:54, Werner LEMBERG <wl@gnu.org> wrote:
> 
> I see the following error:
> 
> rational.cc:68:33: error: call to 'abs' is ambiguous
>  num_ = static_cast<uint64_t> (::abs (n));
>                                ^~~~~
> /usr/include/stdlib.h:129:6: note: candidate function
> int      abs(int) __pure2;
>         ^
> /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:664:1: 
> note: candidate function
> abs(float __lcpp_x) _NOEXCEPT {return fabsf(__lcpp_x);}
> ^
> /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:668:1: 
> note: candidate function
> abs(double __lcpp_x) _NOEXCEPT {return fabs(__lcpp_x);}
> ^
> /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/cmath:672:1: 
> note: candidate function
> abs(long double __lcpp_x) _NOEXCEPT {return fabsl(__lcpp_x);}
> ^

> I'm not a C++ expert, but maybe there is a simple fix
> available?

The ::abs you use, instead of std::abs, is a C compatibility function that the 
C++ allows to be defined in the global namespace, and what I can see the effect 
depends on the compiler. Older compilers may only have the function int 
abs(int) there, and use type conversion before the call, like converting 
int64_t to int. When testing the latest GCC and Clang, there seems to be no 
difference. Also, include the proper C++ headers, <climits> instead of 
<limits.h>, as results also may depend on the compiler.