#24620 closed defect (duplicate)
Singular fails to build on SunOS
Reported by: | jdemeyer | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-duplicate/invalid/wontfix |
Component: | packages: standard | Keywords: | |
Cc: | dimpase | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
On SunOS xenos-sagetest 5.11 11.3 sun4v sparc sun4v
with GCC 5.4.0:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/var/export/home/jeroen/sage/local/var/tmp/sage/build/singular-4.1.0p3.p1/src -I/var/export/home/jeroen/sage/local/var/tmp/sage/build/singular-4.1.0p3.p1/src/factory/include -I/var/export/home/jeroen/sage/local/var/tmp/sage/build/singular-4.1.0p3.p1/src -I/var/export/home/jeroen/sage/local/var/tmp/sage/build/singular-4.1.0p3.p1/src -I/var/export/home/jeroen/sage/local/include -I/var/export/home/jeroen/sage/local/include -O2 -g -m64 -O2 -g -D_XPG6 -pipe -fno-common -O3 -Wno-unused-function -Wno-trigraphs -Wno-unused-parameter -Wunknown-pragmas -Wno-unused-variable -fomit-frame-pointer -fwrapv -fvisibility=default -finline-functions -fno-exceptions -fno-rtti -fno-threadsafe-statics -fno-enforce-eh-specs -fconserve-space -funroll-loops -fno-delete-null-pointer-checks -MT ffields.lo -MD -MP -MF .deps/ffields.Tpo -c ffields.cc -fPIC -DPIC -o .libs/ffields.o ffields.cc: In function 'BOOLEAN nfCoeffIsEqual(coeffs, n_coeffType, void*)': ffields.cc:809:40: error: call of overloaded 'pow(int&, int&)' is ambiguous int c = pow (p->GFChar, p->GFDegree); ^ In file included from /usr/include/math.h:17:0, from ffields.cc:21: /usr/include/iso/math_iso.h:199:21: note: candidate: long double std::pow(long double, int) inline long double pow(long double __X, int __Y) { return ^ /usr/include/iso/math_iso.h:197:21: note: candidate: long double std::pow(long double, long double) inline long double pow(long double __X, long double __Y) { return ^ /usr/include/iso/math_iso.h:166:15: note: candidate: float std::pow(float, int) inline float pow(float __X, int __Y) { return ^ /usr/include/iso/math_iso.h:161:15: note: candidate: float std::pow(float, float) inline float pow(float __X, float __Y) { return __powf(__X, __Y); } ^ /usr/include/iso/math_iso.h:141:16: note: candidate: double std::pow(double, int) inline double pow(double __X, int __Y) { return ^ /usr/include/iso/math_iso.h:64:15: note: candidate: double std::pow(double, double) extern double pow __P((double, double));
Change History (15)
comment:1 Changed 22 months ago by
- Description modified (diff)
- Summary changed from singular fails to build on SunOS to Singular fails to build on SunOS
comment:2 Changed 22 months ago by
comment:3 follow-up: ↓ 4 Changed 22 months ago by
I guess you must be using gas
, misnamed as as
. Make sure that the real Sunas
is first in your path.
comment:4 in reply to: ↑ 3 Changed 22 months ago by
Replying to dimpase:
I guess you must be using
gas
, misnamed asas
. Make sure that the real Sunas
is first in your path.
Why would the assembler interfere with the compilation of pow()
? That makes no sense to me.
comment:5 follow-up: ↓ 6 Changed 22 months ago by
sorry, I meant ld
...
Anyhow, could you show what you have in $PATH, and in $LD_LIBRARY_PATH.
comment:6 in reply to: ↑ 5 Changed 22 months ago by
Replying to dimpase:
sorry, I meant
ld
...
Same comment... Why would the linker interfere with the compilation of pow()
? That makes no sense to me.
comment:7 follow-up: ↓ 8 Changed 22 months ago by
There is some kind of caching involved. I just logged in, and (with Solaris ld
, whether it's relevant or not), it worked:
// t.cc #include <cmath> int main() { // using namespace std; int i,j,k; i = 2; j = 10; k = pow(i,j); return k; }
and g++ t.cc
worked.
But then
$ PATH=/opt/csw/gnu:$PATH ld --version GNU ld (GNU Binutils) 2.24 ... $ PATH=/opt/csw/gnu:$PATH g++ t.cc t.cc: In function ‘int main()’: t.cc:8:12: error: call of overloaded ‘pow(int&, int&)’ is ambiguous ...
And now going back to the correct linker does not help either.
Anyhow, I have managed to build Singular without any changes to the C++ source few times in row (it needed the linking fixes, but that's another story).
comment:8 in reply to: ↑ 7 Changed 22 months ago by
Replying to dimpase:
There is some kind of caching involved.
That would be really surprising.
I just logged in, and (with Solaris
ld
, whether it's relevant or not), it worked:// t.cc #include <cmath> int main() { // using namespace std; int i,j,k; i = 2; j = 10; k = pow(i,j); return k; }and
g++ t.cc
worked.
This never worked for me. I get
t.cc: In function ‘int main()’: t.cc:8:12: error: call of overloaded ‘pow(int&, int&)’ is ambiguous k = pow(i,j); ^ In file included from /usr/include/math.h:17:0, from /usr/gcc/5/include/c++/5.4.0/cmath:44, from t.cc:1: /usr/include/iso/math_iso.h:199:21: note: candidate: long double std::pow(long double, int) inline long double pow(long double __X, int __Y) { return ^ /usr/include/iso/math_iso.h:197:21: note: candidate: long double std::pow(long double, long double) inline long double pow(long double __X, long double __Y) { return ^ /usr/include/iso/math_iso.h:166:15: note: candidate: float std::pow(float, int) inline float pow(float __X, int __Y) { return ^ /usr/include/iso/math_iso.h:161:15: note: candidate: float std::pow(float, float) inline float pow(float __X, float __Y) { return __powf(__X, __Y); } ^ /usr/include/iso/math_iso.h:141:16: note: candidate: double std::pow(double, int) inline double pow(double __X, int __Y) { return ^ /usr/include/iso/math_iso.h:64:15: note: candidate: double std::pow(double, double) extern double pow __P((double, double));
comment:9 Changed 22 months ago by
Replacing pow
by std::pow
does work though.
comment:10 follow-up: ↓ 13 Changed 22 months ago by
One possible explanation is LTO optimisation, coupled (perhaps) with ccache.
You try to compile the example above, and you manage, say, by adding std::
to pow
.
This get stored in ccache, and used by the compiler next time to compile the code without that std::
...
comment:11 Changed 22 months ago by
Yes, sure, it does work (or using namespace std;
works too). The real question is whether Singular is adhering to c++11 (or so) standard, or it relies on an old behaviour of C++ which is platform-dependent.
comment:12 Changed 22 months ago by
Note that http://en.cppreference.com/w/cpp/numeric/math/pow specifically talks about std::pow
. Without std::
of using namespace std;
all bets are off, at least it looks like this to me.
comment:13 in reply to: ↑ 10 Changed 22 months ago by
Replying to dimpase:
One possible explanation is LTO optimisation
This error happens before linking. I really don't see how linking could have anything to do with it.
coupled (perhaps) with ccache.
Are you explicitly using ccache
? I don't think that it's enabled by default on that machine.
This get stored in ccache, and used by the compiler next time to compile the code without that
std::
...
ccache wouldn't just ignore "std::
". The sources with and without std::
are obviously different.
comment:14 Changed 22 months ago by
- Milestone changed from sage-8.2 to sage-duplicate/invalid/wontfix
- Resolution set to duplicate
- Status changed from new to closed
I'm folding this in #24611.
comment:15 Changed 22 months ago by
I'm not using ccache
globally, I'm using it as a Sage package.
Note that the error messages ...note: candidate: long double std::pow(...)
, so perhaps it'd willing to consider int std::pow(...)
if it was in ccache
.
And it could be that some tests I did where at Sage prompt, thus using ccache
. (This is just a conjecture of course).
This is interesting; it would be good to understand why I am not seeing this
pow
errors any more...