Upgrade to Cysignals 1.10.2

[slel]

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

CC: @antonio-rojas @embray @kiwifb @timokau @infinity0 @jdemeyer @slel @tobihan

Component: packages: standard

Keywords: upgrade, cysignals

Author: Jeroen Demeyer

Branch/Commit: a2ac9c7

Reviewer: Travis Scrimshaw, Erik Bray

Issue created by migration from https://trac.sagemath.org/ticket/27070

[jdemeyer]

comment:2

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]

Branch: u/jdemeyer/upgrade_to_cysignals_1_10_0

[jdemeyer]

Author: Jeroen Demeyer

[jdemeyer]

New commits:

2f60b3c

Upgrade to Cysignals 1.10.0

[jdemeyer]

Commit: 2f60b3c

[timokau]

comment:8

Why is this a blocker?

[tscrim]

Reviewer: Travis Scrimshaw

[tscrim]

comment:9

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]

comment:10

It's a blocker because it fixes #27384

[jdemeyer]

comment:12

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

[embray]

comment:13

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]

comment:14

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]

comment:15

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]

comment:16

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

[sagetrac-git]

Changed commit from 2f60b3c to 04601fe

[sagetrac-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]

comment:21

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]

comment:22

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]

comment:23

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]

comment:24

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

[jhpalmieri]

comment:25

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

[jdemeyer]

comment:26

Confirmed indeed with clang.

[jdemeyer]

comment:27

The problem is essentially that this doesn't compile:

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

[sagetrac-git]

Changed commit from 04601fe to 14b1551

[sagetrac-git]

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

14b1551

Upgrade to Cysignals 1.10.2

[sagetrac-git]

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

a2ac9c7

cysignals should be a normal dependency

[sagetrac-git]

Changed commit from 14b1551 to a2ac9c7

[jdemeyer]

comment:32

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

[embray]

comment:33

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

[embray]

Changed reviewer from Travis Scrimshaw to Travis Scrimshaw, Erik Bray

[vbraun]

Changed branch from u/jdemeyer/upgrade_to_cysignals_1_10_0 to a2ac9c7