Opened 22 months ago

Closed 22 months ago

Last modified 22 months ago

#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 jdemeyer)

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 jdemeyer

  • 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 dimpase

This is interesting; it would be good to understand why I am not seeing this pow errors any more...

comment:3 follow-up: Changed 22 months ago by dimpase

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 jdemeyer

Replying to dimpase:

I guess you must be using gas, misnamed as as. 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: Changed 22 months ago by dimpase

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 jdemeyer

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: Changed 22 months ago by dimpase

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).

Last edited 22 months ago by dimpase (previous) (diff)

comment:8 in reply to: ↑ 7 Changed 22 months ago by jdemeyer

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 jdemeyer

Replacing pow by std::pow does work though.

comment:10 follow-up: Changed 22 months ago by dimpase

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 dimpase

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 dimpase

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 jdemeyer

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 jdemeyer

  • 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 dimpase

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).

Note: See TracTickets for help on using tickets.