Upgrade to Cysignals 1.10.2

[slelievre]

• Tarball: ​https://files.pythonhosted.org/packages/51/5f/727aa099de5c60b3fb42cdde72097277803dabe78b177afdb5b835bbf909/cysignals-1.10.2.tar.gz

This is a blocker because it fixes #27384 which is required to run GAP on Cygwin.

[jdemeyer]

Fine for me if somebody wants to do this, but there is no real reason for this upgrade. I mainly made the new release to answer to a Python bug.

[jdemeyer]

New commits:

​2f60b3c

Upgrade to Cysignals 1.10.0

[gh-timokau]

Why is this a blocker?

[tscrim]

I am not entirely sure. However, I am sending this off to the buildbots, so it is somewhat moot (but it would still be good to have an answer Jeroen ;)).

[jdemeyer]

It's a blocker because it fixes #27384

[jdemeyer]

This is failing to build on OS X on conda-forge: ​https://github.com/conda-forge/cysignals-feedstock/pull/19 (despite cysignals on OS X being tested on Travis CI).

[embray]

Replying to jdemeyer:

It's a blocker because it fixes #27384

Which itself is not really a blocker (though it is a bad issue) except to the extent that it's a prerequisite to fixing #27214 which could also be argued is not a blocker, but it is a pretty severe problem the more and more I look at it.

[embray]

Since the build problem is just a question of building the tests on clang do we really care about that here, or do you need to make a 1.10.1?

[jdemeyer]

Replying to embray:

Since the build problem is just a question of building the tests on clang do we really care about that here, or do you need to make a 1.10.1?

We do care if the problem with conda-forge also exists on the computers of Sage users. At this point, I don't know if the build failure is specific to Conda (and I guess it's not).

[embray]

Okay, I just wasn't sure if the tests were built by default. But if so then that's a reasonable caution I suppose.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​04601fe

Upgrade to Cysignals 1.10.1

[vbraun]

I'm getting this with 1.10.0 on OSX, please check before setting back to positive review:

[fpylll-0.4.1dev]     In file included from build/src/fpylll/fplll/integer_matrix.cpp:697:
[fpylll-0.4.1dev]     In file included from /Users/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/cysignals/struct_signals.h:45:
[fpylll-0.4.1dev]     /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include/stdatomic.h:75:26: error: reference to 'memory_order' is ambiguous
[fpylll-0.4.1dev]     void atomic_thread_fence(memory_order);
[fpylll-0.4.1dev]                              ^
[fpylll-0.4.1dev]     /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include/stdatomic.h:68:3: note: candidate found by name lookup is 'memory_order'
[fpylll-0.4.1dev]     } memory_order;
[fpylll-0.4.1dev]       ^
[fpylll-0.4.1dev]     /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/atomic:588:3: note: candidate found by name lookup is 'std::__1::memory_order'
[fpylll-0.4.1dev]     } memory_order;
[fpylll-0.4.1dev]       ^

[jdemeyer]

Which OS X machine is that? I cannot reproduce it on your osx.fritz.box (I tried cysignals-1.10.1 but probably that doesn't make a difference for this error).

[vbraun]

Yes, that one. Whats the compiler invocation? I have

    gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -I/Users/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/cysignals -I/Users/buildslave-sage/slave/sage_git/build/local/include -I/Users/buildslave-sage/slave/sage_git/build/local/lib/python2.7/site-packages/numpy/core/include -I/Users/buildslave-sage/slave/sage_git/build/local/include/python2.7 -c build/src/fpylll/fplll/integer_matrix.cpp -o build/temp.macosx-10.9-x86_64-2.7/build/src/fpylll/fplll/integer_matrix.o -std=c++11

[vbraun]

You built sage's gcc, the buildbot doesn't and runs XCode clang

[jhpalmieri]

I get the same error on OS X (not building Sage's gcc).

[jdemeyer]

Confirmed indeed with clang.

[jdemeyer]

The problem is essentially that this doesn't compile:

using namespace std;
#include <atomic>
#include <stdatomic.h>

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​14b1551

Upgrade to Cysignals 1.10.2

[git]

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

​a2ac9c7

cysignals should be a normal dependency

[jdemeyer]

I tested on that OS X machine that the cysignals test suite passes and that Sage builds.

[embray]

I'm going to test this on Cygwin in a few minutes, but I don't expect any problems.