Upgrade to giac 1.5 fails to build with older libstdc++

[embray]

#26315 broke building giac on some systems that have a old-ish libstdc++. It is completely mysterious to me why this broke when it worked before, and without a repository it's very difficult to determine what change between the versions is responsible, as there is little difference between the two versions in the relevant code.

Nevertheless, it can be fixed by explicitly using std::isnan and std::isinf so that there is no risk of them conflicting with the libc math.h equivalents thereof.

[embray]

Also I have no idea what the FIR_LINUX macro here means. There is no documentation mentioning it and it is not defined anywhere.

[jdemeyer]

Bad branch?

[jdemeyer]

This might also have been caused by #26787.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​2651e20

Trac #27263: Added patch which fixes this issue in GIAC

[embray]

Replying to jdemeyer:

This might also have been caused by #26787.

According to my research this occurs with or without -std=c++11 but I haven't explicitly tested that.

I will also try to bring it up upstream in case there is any idea.

---

New commits:

​2651e20

Trac #27263: Added patch which fixes this issue in GIAC

[embray]

I still don't fully understand what #26787 does though so it's possible.

[embray]

Okay, confirmed that it is #26787 after all. If I just put unset CXX in the spkg-install for giac it builds. Something like that might be better than patching...

[embray]

Right now in sage-env-config I have

export CONFIGURED_CXX="g++ -std=gnu++11 -std=gnu++11"

I don't know why the -std=gnu++11 is repeated. Conceivably it might also matter that it's gnu++11 and not c++11. Perhaps this older gcc is not fully c++11-compatible?

In any case, what would be the best approach here, do you think? Would it be reasonable to just unset CXX in the spkg-install?

[jdemeyer]

Why not just apply the patch? I'd rather not mess with environment variables.

[embray]

I guess, I don't really know what impact the patch has on other systems. But it does seem clear to me: Just explicitly use the isnan in the std namespace. I assume there's no reason that should go wrong...

[dimpase]

LGTM

[jdemeyer]

I think you should bump the giac patchlevel such that this upgrade is actually tested.

[fbissey]

Replying to embray:

Right now in sage-env-config I have

export CONFIGURED_CXX="g++ -std=gnu++11 -std=gnu++11"

The only way I think you can end up with that is for CXX to be g++ -std=gnu++11 at configuration time. The macro will then happily add another one because it is fairly stupid.

I don't know why the -std=gnu++11 is repeated. Conceivably it might also matter that it's gnu++11 and not c++11.

Don't think so but I am a C++ bigwig.

Perhaps this older gcc is not fully c++11-compatible?

Most certainly. Before gcc-5 C++11 support was experimental and the implementation was not fixed in stone.

In any case, what would be the best approach here, do you think? Would it be reasonable to just unset CXX in the spkg-install?

I'd rather have that little patch here.

[dimpase]

Replying to jdemeyer:

I think you should bump the giac patchlevel such that this upgrade is actually tested.

In theory yes, but this only matters for systems that otherwise simply cannot built giac, so you don't need to do this bumping for all practical purposes.