State of sage built with clang/clang++ on OS X

[Francois Bissey]

So on another thread there was talk about whether we could
build sage with clang+gfortran on OS X.
Well it is not that bad and a little push in the right place would probably
get use 95% there.

I couldn’t build sagelib, I didn’t manage to get there. Here are the
packages that fail to build with clang in sage 7.4.beta4 on OS X:
ratpoints
lcalc
pynac
linbox
symmetrica
gfan

ratpoints: there is an ancient ticket (#12473). Surprisingly it is a
C language problem. ratpoints rely on a GNU extension to use nested
functions. I tried to untangle the first specimen I encountered
before realising that it was quite an amount of work (the nested function
sees and uses a number of variables from the “host” function that
are in scope like they were global variables, this makes things just insane).

lcalc: is no surprise. It uses a number of obsolete features, not sure
how long gcc itself will build it.

pynac:
https://github.com/pynac/pynac/pull/192
https://github.com/pynac/pynac/issues/193
for starters.

linbox:
https://github.com/linbox-team/linbox/issues/39
more on linbox specifically later.

symmetrica:
In the first instance a function returning an “int” has return
statement with no values. Should be trivial but I didn’t
dig too much.

gfan:
some C++ constructor problem.

On most of these switching to gcc/g++ solved the problem expect for
linbox which revealed some tricky C++ problems with that approach.
linbox uses fflas-ffpack and givaro, themselves having been compiled
with clang++.
In another post I mentioned that most vendors (clang and GNU in particular)
where following a common ABI for C++. The problem is that there is now
several versions of the ABI and g++ and clang++ on OS X default on
different one. You can get g++ to change to the right ABI but then the
linker get confused thinking you mix different architectures. This is probably
solvable but show that it would be more sane to compile all C++ libraries
that will be included in sage with the same compiler. Stuff called by pexpect
doesn’t matter so much, but in the list above that means lcalc, pynac and
linbox need to be fixed [ratpoints and symmetrica are C, gfan is used via
pexpect].

I was surprised sympow didn’t make it in the list but it did compile.

François

[Jeroen Demeyer]

On 2016-09-15 23:21, Francois Bissey wrote:
> lcalc: is no surprise. It uses a number of obsolete features, not sure
> how long gcc itself will build it.

This is a bit off-topic, but for lcalc we should also at some
investigate whether we really need the package. It could very well be
that all features that it offers exist in PARI now.

[Francois Bissey]

package elimination totally count as on topic to further this one.

François

[Travis Scrimshaw]

I could look into the Symmetrica code next week for things like you mentioned, but I don't have access to an OS X machine to test.

Best,
Travis

[Francois Bissey]

In theory you just need clang.

François

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Francois Bissey]

Reanimating https://trac.sagemath.org/ticket/12426
There is a ticket for symmetrica, if you still want to do it, I’d rather you
fix the code with a patch than with a compilation flags as is suggested in #12439.

François

[Travis Scrimshaw]

On Saturday, September 17, 2016 at 2:48:40 AM UTC-5, François wrote:

Reanimating https://trac.sagemath.org/ticket/12426
There is a ticket for symmetrica, if you still want to do it, I’d rather you
fix the code with a patch than with a compilation flags as is suggested in #12439.

Just saw that ticket, and I was thinking the same as you. This is now in my todo list.

I know this is probably in the dumb question category, but....Should I worry about anything (e.g., no longer able to build Sage) by installing clang via apt-get?

Best,
Travis

[Francois Bissey]

I don’t know about debian based distro specifically but installing clang
shouldn’t remove gcc, they are orthogonal to each other.

When you try building a specific package try
CC=clang CXX=clang++ ./sage -f symmetrica
for example. Yes there is a possibility of your
sage install breaking after that. But since
symmetrica looks like just C code it shouldn’t.
If you try to fix linbox you should get ready for
some pain.

Cheers,
François

[Thierry Dumont]

Le 17/09/2016 à 22:15, Francois Bissey a écrit :
> I don’t know about debian based distro specifically but installing clang
> shouldn’t remove gcc, they are orthogonal to each other.
>

I confirm what François says:

You can install clang and the gcc programs togeteher on Debian and
Debian like distributions.

Yours,
t.

[Travis Scrimshaw]

Thank you both. I'm installing it now.

Best,
Travis

[Dima Pasechnik]

On Thursday, September 15, 2016 at 9:21:34 PM UTC, François wrote:

So on another thread there was talk about whether we could
build sage with clang+gfortran on OS X.
Well it is not that bad and a little push in the right place would probably
get use 95% there.

I couldn’t build sagelib, I didn’t manage to get there. Here are the
packages that fail to build with clang in sage 7.4.beta4 on OS X:
ratpoints
lcalc
pynac
linbox
symmetrica
gfan

ratpoints: there is an ancient ticket (#12473). Surprisingly it is a
C language problem. ratpoints rely on a GNU extension to use nested
functions. I tried to untangle the first specimen I encountered
before realising that it was quite an amount of work (the nested function
sees and uses a number of variables from the “host” function that
are in scope like they were global variables, this makes things just insane).

I posted a preliminary fix on #12473. Please try with clang... 

[François Bissey]

Hi all,

this is the status after about two weeks

On 16/09/16 09:21, Francois Bissey wrote:
> I couldn’t build sagelib, I didn’t manage to get there. Here are the
> packages that fail to build with clang in sage 7.4.beta4 on OS X:
> ratpoints

#12473 for this has positive review

> lcalc

#12437 for this is in "need_review"

> pynac

New upstream upgrade ticket at #21623
has all the fix. Needs_review :)

> linbox

No news from upstream at
https://github.com/linbox-team/linbox/issues/39
contributions welome.

> symmetrica

Someone volunteered for the trivial fix of changing
"return;" to "return 0;" in a few places at #12439...

> gfan

#12440 is waiting for review.

Linbox needs to be fixed before we can even try
to compile sagelib with clang which is the next natural
step.

Of course there is a chance that the singular and fplll
upgrades add to the list of broken things, but I am
confident that it wouldn't be too hard to fix.

Cheers,
Francois

[Travis Scrimshaw]

 

> symmetrica

Someone volunteered for the trivial fix of changing
"return;" to "return 0;" in a few places at #12439...

That would be me, and I had less time than I thought I would this past week. I am working on it now.

Best,
Travis
 

[Francois Bissey]

> On 3/10/2016, at 09:33, François Bissey <francoi...@canterbury.ac.nz> wrote:
>
>> linbox
>
> No news from upstream at
> https://github.com/linbox-team/linbox/issues/39
> contributions welome.

Well as it turns out the problem is only in the interface with
fplll which we are going to disable in the next fplll upgrade.
Word from upstream is that this particular interface is not
currently used by sage so it is all right to disable it.

With fplll disabled in linbox all the standard packages are
now successfully building and installing with clang.

The next challenge is sagelib itself:
[sagelib-7.4.beta6] [ 1/387] clang -fno-strict-aliasing -I/Users/fbissey/build/sage/local/var/tmp/sage/build/python2-2.7.10.p2/include -DNDEBUG -g -fwrapv -O3 -Wall -Wno-unused -I/Users/fbissey/build/sage/local/lib/python2.7/site-packages/cysignals -I/Users/fbissey/build/sage/local/include -I/Users/fbissey/build/sage/local/include/python2.7 -I/Users/fbissey/build/sage/local/lib/python2.7/site-packages/numpy/core/include -I/Users/fbissey/build/sage/src -I/Users/fbissey/build/sage/src/sage/ext -I/Users/fbissey/build/sage/src/build/cythonized -I/Users/fbissey/build/sage/src/build/cythonized/sage/ext -I/Users/fbissey/build/sage/local/include/python2.7 -c /Users/fbissey/build/sage/src/build/cythonized/sage/finance/time_series.c -o build/temp.macosx-10.9-x86_64-2.7/Users/fbissey/build/sage/src/build/cythonized/sage/finance/time_series.o -fno-strict-aliasing
[sagelib-7.4.beta6] In file included from /Users/fbissey/build/sage/src/build/cythonized/sage/finance/time_series.c:317:
[sagelib-7.4.beta6] In file included from /Users/fbissey/build/sage/local/lib/python2.7/site-packages/numpy/core/include/numpy/arrayobject.h:4:
[sagelib-7.4.beta6] In file included from /Users/fbissey/build/sage/local/lib/python2.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:18:
[sagelib-7.4.beta6] In file included from /Users/fbissey/build/sage/local/lib/python2.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1777:
[sagelib-7.4.beta6] /Users/fbissey/build/sage/local/lib/python2.7/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
[sagelib-7.4.beta6] #warning "Using deprecated NumPy API, disable it by " \
[sagelib-7.4.beta6] ^
[sagelib-7.4.beta6] /Users/fbissey/build/sage/src/build/cythonized/sage/finance/time_series.c:15275:3: error: non-void function '__pyx_pf_4sage_7finance_11time_series_10TimeSeries_106numpy' should return a value [-Wreturn-type]
[sagelib-7.4.beta6] import_array();
[sagelib-7.4.beta6] ^
[sagelib-7.4.beta6] /Users/fbissey/build/sage/local/lib/python2.7/site-packages/numpy/core/include/numpy/__multiarray_api.h:1532:144: note: expanded from macro 'import_array'
[sagelib-7.4.beta6] #define import_array() {if (_import_array() < 0) {PyErr_Print(); PyErr_SetString(PyExc_ImportError, "numpy.core.multiarray failed to import"); return NUMPY_IMPORT_ARRAY_RETVAL; } }
[sagelib-7.4.beta6] ^
[sagelib-7.4.beta6] 1 warning and 1 error generated.

François

[Dima Pasechnik]

What exactly should be set to start the Sage build using clang rather than gcc?

[Francois Bissey]

In the current state of sage starting from scratch with clang/clang++
via
CC=clang CXX=clang++ make
will trigger the building of sage’s gcc (which is OK on OS X since
you still need gfortran).
The problem is that once you build sage’s gcc, there is a clause
in src/bin/sage-env to use sage’s gcc/g++/gfrotran if it is present
in SAGE_LOCAL/bin:
# Override CC, CPP, CXX, FC if the GCC spkg was installed.
if [ -x "$SAGE_LOCAL/bin/gcc" ]; then
CC=gcc
fi
if [ -x "$SAGE_LOCAL/bin/cpp" ]; then
CPP=cpp
fi
if [ -x "$SAGE_LOCAL/bin/g++" ]; then
CXX=g++
fi
if [ -x "$SAGE_LOCAL/bin/gfortran" ]; then
FC=gfortran
fi
export CC CPP CXX FC

So working on OS X I dirty patched sage-env:
@@ -511,15 +515,15 @@ if [ "$UNAME" = "Darwin" ]; then
fi

# Override CC, CPP, CXX, FC if the GCC spkg was installed.
-if [ -x "$SAGE_LOCAL/bin/gcc" ]; then
- CC=gcc
-fi
-if [ -x "$SAGE_LOCAL/bin/cpp" ]; then
- CPP=cpp
-fi
-if [ -x "$SAGE_LOCAL/bin/g++" ]; then
- CXX=g++
-fi
+#if [ -x "$SAGE_LOCAL/bin/gcc" ]; then
+# CC=gcc
+#fi
+#if [ -x "$SAGE_LOCAL/bin/cpp" ]; then
+# CPP=cpp
+#fi
+#if [ -x "$SAGE_LOCAL/bin/g++" ]; then
+# CXX=g++
+#fi
if [ -x "$SAGE_LOCAL/bin/gfortran" ]; then
FC=gfortran
fi

So with that patch on OS X and starting with
CC=clang CXX=clang++ make
gcc will be built but clang/clang++/gfortran will be used.

Something a little bit less dirty should be done once
we are more advanced.

But at the moment compiling sagelib seems to point to a variety
of problems from numpy to cython and probably other…

François

[Dima Pasechnik]

Do you mean that when you build gfortran you will also build gcc?

And how about Linux with clang(++) and gfortran installed systemwide?

Would this patch still be needed?

(or, would SAGE_INSTALL_GCC=no do?)

[Francois Bissey]

I haven’t tried SAGE_INSTALL_GCC=no on linux or using clang
for a full build on linux. Just one packages here and there.

And yes you cannot build gfortran without gcc a t this time.

François

[Dima Pasechnik]

On Monday, October 3, 2016 at 11:48:22 AM UTC+1, François wrote:

I haven’t tried SAGE_INSTALL_GCC=no on linux or using clang
for a full build on linux. Just one packages here and there.

And yes you cannot build gfortran without gcc a t this time.

this is a limitation of Sage's gcc package, right?

I.e. we'd eventually resurrect gfortran package...

[Jean-Pierre Flori]

On Monday, October 3, 2016 at 4:04:20 PM UTC+2, Dima Pasechnik wrote:

On Monday, October 3, 2016 at 11:48:22 AM UTC+1, François wrote:

I haven’t tried SAGE_INSTALL_GCC=no on linux or using clang
for a full build on linux. Just one packages here and there.

And yes you cannot build gfortran without gcc a t this time.

this is a limitation of Sage's gcc package, right?

I.e. we'd eventually resurrect gfortran package...

Which GCC made harder as they're not distributing separate tarballs anymore.
But splitting gfortran is quite easy.

[Ralf Stephan]

On Sunday, October 2, 2016 at 10:33:38 PM UTC+2, François wrote:

this is the status after about two weeks

ratpoints compiles for you? On Linux with CC=clang CXX=clang++ make

(clang-3.7.0) I can't get past ratpoints.

[Francois Bissey]

You need https://trac.sagemath.org/ticket/12473 for ratpoints.
coming in the next beta.

François

[Ralf Stephan]

I cannot find mention of ecl problems:

[ecl-16.1.2.p2] /home/ralf/sage/local/var/tmp/sage/build/ecl-16.1.2.p2/src/src/c/ffi.d:148:44: error: use of undeclared identifier 'FFI_SYSV'

[ecl-16.1.2.p2]         {((cl_object)(cl_symbols+(1604))), FFI_SYSV},

[ecl-16.1.2.p2]                                            ^

[ecl-16.1.2.p2] /home/ralf/sage/local/var/tmp/sage/build/ecl-16.1.2.p2/src/src/c/ffi.d:149:44: error: use of undeclared identifier 'FFI_SYSV'

[ecl-16.1.2.p2]         {((cl_object)(cl_symbols+(1736))), FFI_SYSV},

[ecl-16.1.2.p2]                                            ^

[Ralf Stephan]

Ah that would be a wrong libffi-devel version on OpenSuSE, shouldn't

this be tested by Sage configure?

Now I get this:

[libgap-4.8.3] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linu

x/bin/ld: .libs/libgap_la-ariths.o: relocation R_X86_64_32S against `libGAP_ZERO

Op' can not be used when making a shared object; recompile with -fPIC

[libgap-4.8.3] .libs/libgap_la-ariths.o: error adding symbols: Bad value

[libgap-4.8.3] clang-3.7: error: linker command failed with exit code 1 (use -v 

to see invocation)

[libgap-4.8.3] Makefile:503: recipe for target 'libgap.la' failed

[Francois Bissey]

> On 4/10/2016, at 20:39, Ralf Stephan <gtr...@gmail.com> wrote:
>
> Ah that would be a wrong libffi-devel version on OpenSuSE, shouldn't
> this be tested by Sage configure?
>

That would explain. Note that I only tested the odd package on linux and
most of what I have done has been on OS X. So there definitely could be
variations.

> Now I get this:
> [libgap-4.8.3] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linu
> x/bin/ld: .libs/libgap_la-ariths.o: relocation R_X86_64_32S against `libGAP_ZERO
> Op' can not be used when making a shared object; recompile with -fPIC
> [libgap-4.8.3] .libs/libgap_la-ariths.o: error adding symbols: Bad value
> [libgap-4.8.3] clang-3.7: error: linker command failed with exit code 1 (use -v
> to see invocation)
> [libgap-4.8.3] Makefile:503: recipe for target 'libgap.la' failed
>

Mixing 32 and 64 bits, there is something very wrong going on there.

François

[Isuru Fernando]

Anybody know why some python extensions with C++ as the language are compiled with -std=c99? I'm using sage-7.5.1

Log is below

https://travis-ci.org/isuruf/staged-recipes/builds/205439821#L6669

Regards,

Isuru Fernando

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscribe@googlegroups.com.

[Francois Bissey]

That’s because python doesn’t do c++ compilation properly out of the box.
That’s https://bugs.python.org/issue1222585
look it up. I will probably patch sage’s python in the near future - when
I have time.

François

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

[Isuru Fernando]

Thanks. This is using conda's python, so will have to patch that as well.


Regards,

Isuru Fernando

On Sun, Feb 26, 2017 at 1:09 PM, Francois Bissey <francoi...@canterbury.ac.nz> wrote:

That’s because python doesn’t do c++ compilation properly out of the box.
That’s https://bugs.python.org/issue1222585
look it up. I will probably patch sage’s python in the near future - when
I have time.

François

> On 26/02/2017, at 20:27, Isuru Fernando <isu...@gmail.com> wrote:
>
> Anybody know why some python extensions with C++ as the language are compiled with -std=c99? I'm using sage-7.5.1
>
> Log is below
>
> https://travis-ci.org/isuruf/staged-recipes/builds/205439821#L6669
>
> Regards,
>
> Isuru Fernando
>

> On Tue, Oct 4, 2016 at 1:14 PM, Francois Bissey <francois.bissey@canterbury.ac.nz> wrote:
>
> > On 4/10/2016, at 20:39, Ralf Stephan <gtr...@gmail.com> wrote:
> >
> > Ah that would be a wrong libffi-devel version on OpenSuSE, shouldn't
> > this be tested by Sage configure?
> >
>
> That would explain. Note that I only tested the odd package on linux and
> most of what I have done has been on OS X. So there definitely could be
> variations.
>
> > Now I get this:
> > [libgap-4.8.3] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linu
> > x/bin/ld: .libs/libgap_la-ariths.o: relocation R_X86_64_32S against `libGAP_ZERO
> > Op' can not be used when making a shared object; recompile with -fPIC
> > [libgap-4.8.3] .libs/libgap_la-ariths.o: error adding symbols: Bad value
> > [libgap-4.8.3] clang-3.7: error: linker command failed with exit code 1 (use -v
> > to see invocation)
> > [libgap-4.8.3] Makefile:503: recipe for target 'libgap.la' failed
> >
>
> Mixing 32 and 64 bits, there is something very wrong going on there.
>
> François
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscribe@googlegroups.com.

> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscribe@googlegroups.com.

> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscribe@googlegroups.com.

[Francois Bissey]

Oh I see, so you will go with clang all the way because that’s the default.
I guess you know the score at https://trac.sagemath.org/ticket/12426
it compiles but doctests are failing left and right. But I haven’t had time
to touch the thing in 3 months.

Francois

> > To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> > To post to this group, send email to sage-...@googlegroups.com.
> > Visit this group at https://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "sage-devel" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> > To post to this group, send email to sage-...@googlegroups.com.
> > Visit this group at https://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

[Dima Pasechnik]

On Sunday, February 26, 2017 at 7:27:45 AM UTC, Isuru Fernando wrote:

Anybody know why some python extensions with C++ as the language are compiled with -std=c99? I'm using sage-7.5.1

Log is below

https://travis-ci.org/isuruf/staged-recipes/builds/205439821#L6669

wow, I didn't know Travis can do OSX builds...

 

Regards,

Isuru Fernando

On Tue, Oct 4, 2016 at 1:14 PM, Francois Bissey <francoi...@canterbury.ac.nz> wrote:

> On 4/10/2016, at 20:39, Ralf Stephan <gtr...@gmail.com> wrote:
>
> Ah that would be a wrong libffi-devel version on OpenSuSE, shouldn't
> this be tested by Sage configure?
>

That would explain. Note that I only tested the odd package on linux and
most of what I have done has been on OS X. So there definitely could be
variations.

> Now I get this:
> [libgap-4.8.3] /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linu
> x/bin/ld: .libs/libgap_la-ariths.o: relocation R_X86_64_32S against `libGAP_ZERO
> Op' can not be used when making a shared object; recompile with -fPIC
> [libgap-4.8.3] .libs/libgap_la-ariths.o: error adding symbols: Bad value
> [libgap-4.8.3] clang-3.7: error: linker command failed with exit code 1 (use -v
> to see invocation)
> [libgap-4.8.3] Makefile:503: recipe for target 'libgap.la' failed
>

Mixing 32 and 64 bits, there is something very wrong going on there.

François

--
You received this message because you are subscribed to the Google Groups "sage-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

[Jeroen Demeyer]

On 2017-02-26 08:39, Francois Bissey wrote:
> That’s because python doesn’t do c++ compilation properly out of the box.

That's true but that has nothing to do with Sage using -std=c99 for C++
extensions.

I know how to fix this but it needs
https://github.com/cython/cython/pull/466
which Cython refuses to merge for reasons which are unclear to me.

So if anybody has any friends at Cython, please ping them...

[Ralf Stephan]

The travis build failed. Usually git maintainers expect the PR submitter to check and fix all such failures.

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/ppRBu2KCE9Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

[Jeroen Demeyer]

On 2017-02-26 10:57, Ralf Stephan wrote:
> The travis build failed. Usually git maintainers expect the PR submitter
> to check and fix all such failures.

I know, but that's not the issue. They didn't say "yes we like your
patch but you need to fix it". They said "why not do Y or Z instead" and
I explained why Y or Z wouldn't work and the discussion ended there...

[Jeroen Demeyer]

On 2017-02-26 08:27, Isuru Fernando wrote:
> Anybody know why some python extensions with C++ as the language are
> compiled with -std=c99? I'm using sage-7.5.1

Fix at https://trac.sagemath.org/ticket/22554