Compiling error when installing due to abs ambiguous call
Vicbcn2001 opened this issue · comments
Hi there!
I am trying to do a regular installation of nloptr 2.0.3 in R 4.1.0 and R 4.2.0 in a Debian 9 OS. However, this error is reported:
In file included from /opt/R-4.1.0/lib/R/library/testthat/include/testthat/testthat.h:65:0,
from /opt/R-4.1.0/lib/R/library/testthat/include/testthat.h:1,
from test-C-API.cpp:12:
test-C-API.cpp:108:35: error: call of overloaded ‘abs(__gnu_cxx::__alloc_traits<std::allocator >::value_type)’ is ambiguous
expect_true(abs(res[1] - 8./27) < 1.0e-4);
^
test-C-API.cpp:108:5: note: in expansion of macro ‘expect_true’
expect_true(abs(res[1] - 8./27) < 1.0e-4);
^~~~~~~~~~~
In file included from /usr/include/c++/6/cstdlib:75:0,
from /usr/include/c++/6/ext/string_conversions.h:41,
from /usr/include/c++/6/bits/basic_string.h:5417,
from /usr/include/c++/6/string:52,
from /usr/include/c++/6/bits/locale_classes.h:40,
from /usr/include/c++/6/bits/ios_base.h:41,
from /usr/include/c++/6/ios:42,
from /usr/include/c++/6/istream:38,
from /usr/include/c++/6/sstream:38,
from /opt/R-4.1.0/lib/R/library/testthat/include/testthat/vendor/catch.h:377,
from /opt/R-4.1.0/lib/R/library/testthat/include/testthat/testthat.h:65,
from /opt/R-4.1.0/lib/R/library/testthat/include/testthat.h:1,
from test-C-API.cpp:12:
/usr/include/stdlib.h:735:12: note: candidate: int abs(int)
extern int abs (int __x) __THROW attribute ((const)) __wur;
^~~
In file included from /usr/include/c++/6/ext/string_conversions.h:41:0,
from /usr/include/c++/6/bits/basic_string.h:5417,
from /usr/include/c++/6/string:52,
from /usr/include/c++/6/bits/locale_classes.h:40,
from /usr/include/c++/6/bits/ios_base.h:41,
from /usr/include/c++/6/ios:42,
from /usr/include/c++/6/istream:38,
from /usr/include/c++/6/sstream:38,
from /opt/R-4.1.0/lib/R/library/testthat/include/testthat/vendor/catch.h:377,
from /opt/R-4.1.0/lib/R/library/testthat/include/testthat/testthat.h:65,
from /opt/R-4.1.0/lib/R/library/testthat/include/testthat.h:1,
from test-C-API.cpp:12:
/usr/include/c++/6/cstdlib:185:3: note: candidate: __int128 std::abs(__int128)
abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
^~~
/usr/include/c++/6/cstdlib:180:3: note: candidate: long long int std::abs(long long int)
abs(long long __x) { return __builtin_llabs (__x); }
^~~
/usr/include/c++/6/cstdlib:172:3: note: candidate: long int std::abs(long int)
abs(long __i) { return __builtin_labs(__i); }
^~~
I have installed g++ version 6.3.0 20170516 and cmake 3.7.2.
Looking for information, I found a post in which they replaced the "abs" function by "fabs". This also worked for me. Could that fixed the issue?
Thank you!
Using fabs() instead of abs() is a very old way of doing it. The better, C++11 or later, way is to properly prefix as std::abs(). See e.g. https://en.cppreference.com/w/cpp/numeric/math/abs
But in short the real problem is that your system is seriously dated -- Debian 9 is old, and g++-6 is really old too. For the systems that matter at CRAN, everything is fine: https://cran.r-project.org/web/checks/check_results_nloptr.html and CRAN would surely signal if an update to current standards was needed. It isn;t under the compilres they use: https://cran.r-project.org/web/checks/check_flavors.html -- as you can see g++ 10, 11 and 12 with one instance of g++-8 in the old/previous Windows release. In short, this is really your local issue.
Thank your for your response. You are right that specifying the std::abs it is more convenient. In any case, would it not be worthy to apply that fix in the code for the next versions as this is an ambiguity, it is very simple to solve and could help potentially a lot of users with outdated systems? Having an up-to-date linux/librarires requires time/resources and depending on the projects it is not always the choice.
I'll prefix the calls to abs. Good catch, thanks!
Yes -- won't hurt. On the other hand AFAIK C++11 gets us that for free and all non-ancient compilers will support it.