7.3.beta2: Compilation failed with Brial

[Johan S. R. Nielsen]

Hi,

I'm having trouble compiling Sage 7.3.beta2 on Arch linux kernel
4.5.4-1, x86_64, 16GB ram.

Looks like compiler-stuff. I have gcc 6.1.1 20160501.

Snip of the compile error. Full brial build-log is attached:

[Francois Bissey]

Do I remember that g++ 6.1 is supposed to default to c++11? It looks like that may be
the issue here. Anyone wants to either submit a fix for brial or work around for the spkg?

François

> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.
> <brial-0.8.4.3.log>....
> [install] [brial-0.8.4.3] In file included from /usr/include/c++/6.1.1/string:48:0,
> [install] [brial-0.8.4.3] from /usr/include/c++/6.1.1/bits/locale_classes.h:40,
> [install] [brial-0.8.4.3] from /usr/include/c++/6.1.1/bits/ios_base.h:41,
> [install] [brial-0.8.4.3] from /usr/include/c++/6.1.1/ios:42,
> [install] [brial-0.8.4.3] from /usr/include/c++/6.1.1/ostream:38,
> [install] [brial-0.8.4.3] from /usr/include/c++/6.1.1/iostream:39,
> [install] [brial-0.8.4.3] from ../../libpolybori/include/polybori/pbori_defs.h:24,
> [install] [brial-0.8.4.3] from ../../libpolybori/include/polybori/BoolePolyRing.h:21,
> [install] [brial-0.8.4.3] from ../../groebner/include/polybori/groebner/FGLMStrategy.h:12,
> [install] [brial-0.8.4.3] from FGLMStrategy.cc:9:
> [install] [brial-0.8.4.3] /usr/include/c++/6.1.1/bits/stl_function.h:387:20: note: 'const polybori::BooleExponent' is not derived from 'const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>'
> [install] [brial-0.8.4.3] { return __x < __y; }
> [install] [brial-0.8.4.3] ~~~~^~~~~
> ... 200 errors like this ...
> [install] [brial-0.8.4.3] In file included from ../../libpolybori/include/polybori/polybori.h:23:0,
> [install] [brial-0.8.4.3] from ../../groebner/include/polybori/groebner/groebner_defs.h:10,
> [install] [brial-0.8.4.3] from ../../groebner/include/polybori/groebner/PairStatusSet.h:20,
> [install] [brial-0.8.4.3] from ../../groebner/include/polybori/groebner/groebner_alg.h:14,
> [install] [brial-0.8.4.3] from ../../groebner/include/polybori/groebner/FGLMStrategy.h:13,
> [install] [brial-0.8.4.3] from FGLMStrategy.cc:9:
> [install] [brial-0.8.4.3] ../../libpolybori/include/polybori/BooleMonomial.h:286:1: note: candidate: polybori::CAuxTypes::bool_type polybori::operator<(const polybori::BooleMonomial&, const polybori::BooleMonomial&)
> [install] [brial-0.8.4.3] operator<(const BooleMonomial& lhs, const BooleMonomial& rhs) {
> [install] [brial-0.8.4.3] ^~~~~~~~
> [install] [brial-0.8.4.3] ../../libpolybori/include/polybori/BooleMonomial.h:286:1: note: no known conversion for argument 1 from 'const polybori::BooleExponent' to 'const polybori::BooleMonomial&'
> [install] [brial-0.8.4.3] Makefile:542: recipe for target 'libpolybori_groebner_la-FGLMStrategy.lo' failed
> [install] [brial-0.8.4.3] make[5]: *** [libpolybori_groebner_la-FGLMStrategy.lo] Error 1
> [install] [brial-0.8.4.3] make[5]: Leaving directory '/home/jsrn/mat/sage_coding_project/local/var/tmp/sage/build/brial-0.8.4.3/src/groebner/src'
> [install] [brial-0.8.4.3] Makefile:372: recipe for target 'all-recursive' failed
> [install] [brial-0.8.4.3] make[4]: *** [all-recursive] Error 1
> [install] [brial-0.8.4.3] make[4]: Leaving directory '/home/jsrn/mat/sage_coding_project/local/var/tmp/sage/build/brial-0.8.4.3/src/groebner'
> [install] [brial-0.8.4.3] Makefile:565: recipe for target 'all-recursive' failed
> [install] [brial-0.8.4.3] make[3]: *** [all-recursive] Error 1
> [install] [brial-0.8.4.3] make[3]: Leaving directory '/home/jsrn/mat/sage_coding_project/local/var/tmp/sage/build/brial-0.8.4.3/src'
> [install] [brial-0.8.4.3] Error building BRiAl
> [install] [brial-0.8.4.3]
> [install] [brial-0.8.4.3] real 0m33.364s
> [install] [brial-0.8.4.3] user 0m29.830s
> [install] [brial-0.8.4.3] sys 0m1.577s
> [install] [brial-0.8.4.3] ************************************************************************
> [install] [brial-0.8.4.3] Error installing package brial-0.8.4.3
> [install] [brial-0.8.4.3] ************************************************************************
> ...
> [install] real 39m8.848s
> [install] user 37m11.613s
> [install] sys 1m58.670s
> [install] ***************************************************************
> [install] Error building Sage.
> [install]
> [install] The following package(s) may have failed to build (not necessarily
> [install] during this run of 'make all'):
> [install]
> [install] * package: brial-0.8.4.3
> [install] log file: /home/jsrn/mat/sage_coding_project/logs/pkgs/brial-0.8.4.3.log
> [install] build directory: /home/jsrn/mat/sage_coding_project/local/var/tmp/sage/build/brial-0.8.4.3
> [install]
> [install] The build directory may contain configuration files and other potentially
> [install] helpful information. WARNING: if you now run 'make' again, the build
> [install] directory will, by default, be deleted. Set the environment variable
> [install] SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.
> [install]
>
>
> Best,
> Johan
>
> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-release...@googlegroups.com.
> To post to this group, send email to sage-r...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.

[Johan S. R. Nielsen]

> Do I remember that g++ 6.1 is supposed to default to c++11? It looks like that may be
> the issue here. Anyone wants to either submit a fix for brial or work around for the spkg?

Looks to me in the logs like gcc gets the flag "-std=gnu++98"...


Does anyone know at least a work-around for this compile error -- I still can't compile Sage
:-S

Best,
Johan

--

[Dima Pasechnik]

Downgrade GCC?

[Johan S. R. Nielsen]

> Downgrade GCC?

Yummi -- a few hours well spent!

Or just not contribute to Sage for a few weeks?

[John H Palmieri]

Can you force Sage to build its own GCC and use that instead?

[Dima Pasechnik]

indeed, just build with SAGE_INSTALL_GCC set, as described in 

http://doc.sagemath.org/html/en/installation/source.html#environment-variables

[Johan S. R. Nielsen]

> indeed, just build with SAGE_INSTALL_GCC set, as described in
> http://doc.sagemath.org/html/en/installation/source.html#environment-variables

Ah cool, thanks -- it seems now to be happily compiling away (though I
can expect it to take a lot longer this time...)


Of course, Brial still seems to be completely broken for gcc-6.1 which
will hit all you non-Arch users as well pretty soon, I guess...

Best,
Johan

--

[Johan S. R. Nielsen]

> indeed, just build with SAGE_INSTALL_GCC set, as described in
> http://doc.sagemath.org/html/en/installation/source.html#environment-variables

<sigh> The shipped GCC doesn't seem to compile with GCC 6.1 </sigh>

That might be related to -std defaulting to "gnu++14" and not "gnu++98";
I don't know. I tried figuring out how I could set the -std flag during
build, but that build system is completely opaque for me.

This is the last few lines spewed out by the failing compiler. Before
that a gazillion C++11 warnings were printed:

[install] [gcc-4.9.3.p1] In file included from ./tm.h:45:0,
[install] [gcc-4.9.3.p1] from ../../src/gcc/cp/except.c:27:
[install] [gcc-4.9.3.p1] ../../src/gcc/defaults.h:126:24: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix]
[install] [gcc-4.9.3.p1] fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%un", ^
[install] [gcc-4.9.3.p1] In file included from ../../src/gcc/cp/except.c:1013:0:
[install] [gcc-4.9.3.p1] cfns.gperf: In function 'const char* libc_name_p(const char*, unsigned int)':
[install] [gcc-4.9.3.p1] cfns.gperf:101:1: error: 'const char* libc_name_p(const char*, unsigned int)' redeclared inline with 'gnu_inline' attribute
[install] [gcc-4.9.3.p1] cfns.gperf:26:14: note: 'const char* libc_name_p(const char*, unsigned int)' previously declared here
[install] [gcc-4.9.3.p1] cfns.gperf: At global scope:
[install] [gcc-4.9.3.p1] cfns.gperf:26:14: warning: inline function 'const char* libc_name_p(const char*, unsigned int)' used but never defined
[install] [gcc-4.9.3.p1] Makefile:1058: recipe for target 'cp/except.o' failed

Best,
Johan

[Dima Pasechnik]

I presume it would be more productive to work on gcc 6.1 support in Sage, rather than on building old gcc...

Did you try reporting the brial problem upstream?

https://github.com/BRiAl/BRiAl

[François Bissey]

Well Andrew Ohana is the maintainer of "brial" but he doesn't have the
time to take care of it apparently. We need someone else to get stuff in it.
Mind you, I have no idea what the fix here would be. Someone with C++
knowledge needs to step in with a fix. Then another designed maintainer
could integrate the few pull requests already there and whatever fix
it is for this.

Francois

> --
> You received this message because you are subscribed to the Google
> Groups "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sage-release...@googlegroups.com

> <mailto:sage-release...@googlegroups.com>.

> To post to this group, send email to sage-r...@googlegroups.com

> <mailto:sage-r...@googlegroups.com>.

[R. Andrew Ohana]

On Tue, May 31, 2016 at 4:30 PM, François Bissey <francoi...@canterbury.ac.nz> wrote:

Well Andrew Ohana is the maintainer of "brial" but he doesn't have the time to take care of it apparently.

I am not the maintainer, as per this discussion or the ticket(s) attached to it, I expressly was not interested in being the maintainer (nor do I have any time now or in the foreseeable future to maintain it). However, despite that discussion no one stepped, and given that I think that it would be best to pursue the other path proposed in that discussion which was the removal of brial/polybori as a standard package (likely making it experimental given that it is unmaintained).

 

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

Visit this group at https://groups.google.com/group/sage-release.
For more options, visit https://groups.google.com/d/optout.

--

Andrew

[François Bissey]

On 06/01/16 12:45, R. Andrew Ohana wrote:
> On Tue, May 31, 2016 at 4:30 PM, François Bissey
> <francoi...@canterbury.ac.nz

> <mailto:francoi...@canterbury.ac.nz>> wrote:
>
> Well Andrew Ohana is the maintainer of "brial" but he doesn't have
> the time to take care of it apparently.
>
>
> I am not the maintainer, as per this

> <https://groups.google.com/forum/#%21searchin/sage-devel/polybori/sage-devel/9Uhnvm3wef8/kkGxWZ9QR0gJ>

> discussion or the ticket(s) attached to it, I expressly was not
> interested in being the maintainer (nor do I have any time now or in the
> foreseeable future to maintain it). However, despite that discussion no
> one stepped, and given that I think that it would be best to pursue the
> other path proposed in that discussion which was the removal of
> brial/polybori as a standard package (likely making it experimental
> given that it is unmaintained).

Yes, sorry for the implication. I shouldn't have made it.
The reality is polybori/brial is connected very deeply
in sage and just removing it will be a lot of work.
If we want to remove it, we need a plan to scrub sage,
it has to be organised.

In the mean time we'll need someone to bump things when
needed, a bit like sagenb. Andrew made it clear he wasn't
that person.

Francois

[R. Andrew Ohana]

On Tue, May 31, 2016 at 6:03 PM, François Bissey <francoi...@canterbury.ac.nz> wrote:

On 06/01/16 12:45, R. Andrew Ohana wrote:

On Tue, May 31, 2016 at 4:30 PM, François Bissey
<francoi...@canterbury.ac.nz
<mailto:francoi...@canterbury.ac.nz>> wrote:

    Well Andrew Ohana is the maintainer of "brial" but he doesn't have
    the time to take care of it apparently.


I am not the maintainer, as per this
<https://groups.google.com/forum/#%21searchin/sage-devel/polybori/sage-devel/9Uhnvm3wef8/kkGxWZ9QR0gJ>
discussion or the ticket(s) attached to it, I expressly was not
interested in being the maintainer (nor do I have any time now or in the
foreseeable future to maintain it). However, despite that discussion no
one stepped, and given that I think that it would be best to pursue the
other path proposed in that discussion which was the removal of
brial/polybori as a standard package (likely making it experimental
given that it is unmaintained).

Yes, sorry for the implication. I shouldn't have made it.
The reality is polybori/brial is connected very deeply
in sage and just removing it will be a lot of work.

If memory serves me from when I was looking into this last year, it is only deeply connected in a couple of relatively isolated components of Sage, so I don't think it would be as much work as you might expect.

 

If we want to remove it, we need a plan to scrub sage,
it has to be organised.

In the mean time we'll need someone to bump things when
needed, a bit like sagenb. Andrew made it clear he wasn't
that person.

Francois

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

--

Andrew

[Johan S. R. Nielsen]

> Dima Pasechnik writes:
> I presume it would be more productive to work on gcc 6.1 support in Sage,
> rather than on building old gcc...

Agreed. As is perhaps evident by now, I'm not knowledgeable enough about
C++ to fix this myself.

FWIW, this is now #20741.

Best,
Johan

[arojas]

 
export CXXFLAGS+=' -std=gnu++98' before ./configure fixes this. Why passing -std=gnu++98 to the compiler command (which brial already does) is not enough, I have no idea.

[Francois Bissey]

That would mean it is not applied consistently.
Will have to dissect the logs.

> On 1/06/2016, at 22:26, arojas <nqn...@gmail.com> wrote:
>
>
> export CXXFLAGS+=' -std=gnu++98' before ./configure fixes this. Why passing -std=gnu++98 to the compiler command (which brial already does) is not enough, I have no idea.
>

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

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

[Francois Bissey]

Could you post your successful log, please?

> On 1/06/2016, at 22:26, arojas <nqn...@gmail.com> wrote:
>
>

> export CXXFLAGS+=' -std=gnu++98' before ./configure fixes this. Why passing -std=gnu++98 to the compiler command (which brial already does) is not enough, I have no idea.
>

[arojas]

El miércoles, 1 de junio de 2016, 12:58:10 (UTC+2), François escribió:

Could you post your successful log, please?

https://paste.kde.org/pz6cabvyk

Note that this is the build log using Arch's PKGBUILD, not sage's spkg-install. The only difference is that we don't apply no-undefined.patch

[Francois Bissey]

Most of that patch is not needed on linux but you should consider including
the bit of it that was in a separate PR until today (when I noticed they had
included it in the no-undefined.patch)
https://github.com/BRiAl/BRiAl/pull/5

> On 1/06/2016, at 23:26, arojas <nqn...@gmail.com> wrote:
>
> The only difference is that we don't apply no-undefined.patch

[Johan S. R. Nielsen]

arojas writes:

> export CXXFLAGS+=' -std=gnu++98' before ./configure fixes this. Why passing -std=gnu++98 to the compiler command (which brial already does) is not enough, I have no idea.

That works! Thanks a lot :-)

Doh: I had tried with CPPFLAGS but the PP of course doesn't stand for
"Plus Plus"...

I'm crossing fingers for no further compile errors...

Best,
Johan

[arojas]

This seems to be the problem:
 checking unordered_map usability... no
 checking unordered_map presence... yes
 configure: WARNING: unordered_map: present but cannot be compiled
 configure: WARNING: unordered_map:     check for missing prerequisite headers?
 configure: WARNING: unordered_map: see the Autoconf documentation
 configure: WARNING: unordered_map:     section "Present But Cannot Be Compiled"
 configure: WARNING: unordered_map: proceeding with the compiler's result

The configure script tests for C++11's unordered_map, which succeeds if using GCC 6. Then it tries to use it later, which of course fails because brial enforces C++98. By exporting -std=gnu++98 before running configure, the test fails so it falls back to boost's unordered_map, and the builds finishes correctly.

[François Bissey]

On 06/02/16 03:23, arojas wrote:
> This seems to be the problem:
> checking unordered_map usability... no
> checking unordered_map presence... yes
> configure: WARNING: unordered_map: present but cannot be compiled
> configure: WARNING: unordered_map: check for missing prerequisite
> headers?
> configure: WARNING: unordered_map: see the Autoconf documentation
> configure: WARNING: unordered_map: section "Present But Cannot Be
> Compiled"
> configure: WARNING: unordered_map: proceeding with the compiler's result
>
> The configure script tests for C++11's unordered_map, which succeeds if
> using GCC 6. Then it tries to use it later, which of course fails
> because brial enforces C++98. By exporting -std=gnu++98 before running
> configure, the test fails so it falls back to boost's unordered_map, and
> the builds finishes correctly.
>

I see, so setting the flag needs to be done earlier in configure.
Looking into that.

Francois

[François Bissey]

On 06/02/16 03:23, arojas wrote:

> This seems to be the problem:
> checking unordered_map usability... no
> checking unordered_map presence... yes
> configure: WARNING: unordered_map: present but cannot be compiled
> configure: WARNING: unordered_map: check for missing prerequisite
> headers?
> configure: WARNING: unordered_map: see the Autoconf documentation
> configure: WARNING: unordered_map: section "Present But Cannot Be
> Compiled"
> configure: WARNING: unordered_map: proceeding with the compiler's result
>
> The configure script tests for C++11's unordered_map, which succeeds if
> using GCC 6. Then it tries to use it later, which of course fails
> because brial enforces C++98. By exporting -std=gnu++98 before running
> configure, the test fails so it falls back to boost's unordered_map, and
> the builds finishes correctly.
>
>

Hum, this is set in `common.mk` instead of the configure script.
This will have to be moved back to configure.ac. I should check it
will work fine with C++11 then I can test for different standard in a
descending way.

Francois

[François Bissey]

C++11 appears to be a bit much for brial, but moving the -std=gnu++98
into configure before any tests are run does appear to work here and
I would hope with g++6.1.

Francois

[Florent Hivert]

I just wan't to report that eclib have exactly the same problem.

Cheers,

Florent

[Volker Braun]

On Monday, June 6, 2016 at 5:10:36 AM UTC-4, hivert wrote:

> C++11 appears to be a bit much for brial, but moving the -std=gnu++98
> into configure before any tests are run does appear to work here and
> I would hope with g++6.1.

Which is of course not a long-term viable solution, but only a short-term bugfix.

 

I just wan't to report that eclib have exactly the same problem. 

Probably not, the issue in brial was that the fallback for compiling without unordered_map was broken. I patched that already, so there isn't anything left to see here.

 

[Florent Hivert]

Dear Vorlker,

Sorry I wasn't clear. What I reported is that the following packages
- brial
- eclib
- ppl
- singular
Doesn't compile on arch where the standard compiler is gcc-6.1 whose default
is to use c++11.

For those package, if the option -std=gnu++98 is not set. The compilation
fails. I didn't went all the way to check why.

Cheers,

Florent

[François Bissey]

While some of that stuff is not completely surprising, some is.
I have compiled a number of those with gcc-5.3 and -std=c++11
for various reasons. Could you provide log for eclib, ppl (ok
that one is new) and singular. Also possibly ntl as things happening
there will affect eclib and singular (and flint actually).

Francois

[Florent Hivert]

On Tue, Jun 07, 2016 at 01:51:05PM +1200, François Bissey wrote:
> While some of that stuff is not completely surprising, some is.
> I have compiled a number of those with gcc-5.3 and -std=c++11
> for various reasons. Could you provide log for eclib, ppl (ok
> that one is new) and singular. Also possibly ntl as things happening
> there will affect eclib and singular (and flint actually).

The problem happened yesterday morning on one of my student machine. I'll ask
him for the log. Unfortunately, he told me yesterday evening that his machine
crashed badly (probably a disk failure). So I'm not sure how long it will take
to get back those logs.

Cheers,

Florent

[Johan S. R. Nielsen]

I just want to follow up on my compilation misadventures: I'm still not
able to compile Sage with gcc-6.1 on Arch. After two weeks of not being
able to review tickets, I have now rolled back my gcc and can get back
to work.

I managed to compile Brial using the `CXXFLAGS= -std=gnu++98` as
explaioned by Florent Hivert. The compilation then continues for a
while, until it fails with Singular, apparently with similar
C++11-exceptions. This time, setting `CPPFLAGS= -std=gnu++98` seems to
be the right thing to do. Unfortunately, then compilation immediately
fails since autoconf fails in locating gmp.h:

...
[singular-3.1.7p1.p1] checking for gmp.h... no
[singular-3.1.7p1.p1] checking for MP.h... no
[singular-3.1.7p1.p1] checking for MPT.h... no
[singular-3.1.7p1.p1] checking for factory.h... no
[singular-3.1.7p1.p1] checking for factor.h... no
[singular-3.1.7p1.p1] checking for omalloc.h... no
[singular-3.1.7p1.p1] checking which tmp dir to use... /home/jsrn/mat/sage_coding_project/local/var/tmp/sage/build/singular-3.1.7p1.p1/src/latest/tmp
[singular-3.1.7p1.p1] checking whether to configure and build omalloc... yes
[singular-3.1.7p1.p1] configure: error: can not find gmp
[singular-3.1.7p1.p1] Unable to configure Singular.
...

I can include gmp.h in cpp files and compile them just fine with or
without the -std=gnu++98 flag. So I don't understand this error.

Best,
Johan

--

[leif]

Johan S. R. Nielsen wrote:

This might be related to what Singular does with gmp.h, cf. #14737.


-leif

[Francois Bissey]

May you should post the associated config.log.
For singular it is usually not enough to define CPPFLAGS.
I would have gone with CXX=“g++ -std=gnu++98” there
are places in singular where CPPFLAGS/CFLAGS are not used.

François

[leif]

Francois Bissey wrote:
> May you should post the associated config.log.

Yep, emphasis on "the associated", as there's a chain of configure runs
in different Singular folders.

I'm not entirely sure, but presumably this 'configure' check for GMP
already uses the generated local "copy" of gmp.h, so its contents may be
relevant as well.

> For singular it is usually not enough to define CPPFLAGS.
> I would have gone with CXX=“g++ -std=gnu++98” there
> are places in singular where CPPFLAGS/CFLAGS are not used.

IIRC users' CXXFLAGS are dropped (or effectively overwritten) at least
in many places, while CPPFLAGS aren't, and our patches used to replace
all instances of hardcoded 'g++' by CXX, so Francois' suggestion may
work, although what's used in 'configure' tests (as opposed to
Makefiles) is often a different thing.

FWIW, passing '-std=gnu++98' when compiling C should only give a warning
(unless '-Werror' or the like is passed as well).


-leif

[leif]

Francois Bissey wrote:
> May you should post the associated config.log.
> For singular it is usually not enough to define CPPFLAGS.
> I would have gone with CXX=“g++ -std=gnu++98” there
> are places in singular where CPPFLAGS/CFLAGS are not used.

Oh, the Singular build errors with GCC 6.1 (C++14) are trivial to fix
(see attached patch); no need to pass '-std=...'.

There are also some *new* warnings w.r.t. C++11 (which might become
errors in the future) we could easily fix as well.


The other spkgs affected by stricter C++ compliance (C++11/C++14) of GCC
6.x are the usual suspects (except for Lcalc, which we apparently
already fixed sufficiently in the past):

BRiAl, eclib (probably just because of included NTL headers), gfan,
LinBox, and PPL.

All of these build with '-std=gnu++98' (but not '-std=gnu++11), e.g. by
adding something like

# GCC 6.x defaults to '-std=gnu++14', which $PKG doesn't yet compile with
case `$CXX -dumpversion` in
6|6.*)
echo "Adding '-std=gnu++98' to CXXFLAGS:"
CXXFLAGS="$CXXFLAGS -std=gnu++98"
echo " $CXXFLAGS"
;;
esac

to their spkg-install files.


So far I've successfully built Sage 7.2 with GCC 6.1 and the above
changes, except for some Sage library modules which include LinBox
headers, and hence have to be built with '-std=gnu++98', too.


-leif

[Benjamin Hackl]

Hi,

I have a very similar setup (gcc 6.1.1 20160602 on Arch Linux), and I'm struggling quite hard to build 7.2:

- I'm using the patch from https://trac.sagemath.org/ticket/20738 in order to get singular to build. (Which works, as far as I can tell.)

- I could build (the originally failing) packages gfan, ppl, eclib, and linbox by adding the snippet above before the "./configure" in the respective spkg-install, however

- brial still failed, which I could resolve by setting CXXFLAGS globally, i.e. by calling  CXXFLAGS="$CXXFLAGS -std=gnu++98" make   (this actually puzzles me, because the CXXFLAGS set in the spkg-install file were picked up; I was quite sure to see that in the logfile...)

The next failure then occurs when the Sage library modules are compiled: as I couldn't find out how to add '-std=gnu++98' for a single module, I called  CFLAGS="$CFLAGS -std=gnu++98" make  (which might be the culprit; I know too little about how the building process works ...), let it compile for a while and switched back to just "make -j4" by interrupting and restarting. This lets the compilation of the modules finish, but...

... then I get a segfault (last few lines are at http://pastebin.com/CBXhNN9P -- and I uploaded my full install.log to http://benjamin-hackl.at/downloads/behackl-20160629.install.log).

Unfortunately, the reason for this is not that obvious to me---does anyone have an idea or suggestions (besides downgrading my gcc...)? :-|

Benjamin

[leif]

Benjamin Hackl wrote:
> Hi,
>
> I have a very similar setup (gcc 6.1.1 20160602 on Arch Linux), and I'm
> struggling quite hard to build 7.2:
>
> - I'm using the patch from https://trac.sagemath.org/ticket/20738 in
> order to get singular to build. (Which works, as far as I can tell.)
> - I could build (the originally failing) packages gfan, ppl, eclib, and
> linbox by adding the snippet above before the "./configure" in the
> respective spkg-install, however
> - brial still failed, which I could resolve by setting CXXFLAGS
> globally, i.e. by calling CXXFLAGS="$CXXFLAGS -std=gnu++98" make
> (this actually puzzles me, because the CXXFLAGS set in the spkg-install
> file were picked up; I was quite sure to see that in the logfile...)

This is because '-std=c++98' is added in the Makefiles, but not used
during 'configure'.

See earlier in this thread or (the link referenced from)
https://trac.sagemath.org/ticket/20741 .

> The next failure then occurs when the Sage library modules are compiled:
> as I couldn't find out how to add '-std=gnu++98' for a single module,

The "clean" way is to add

# distutils: extra_compile_args = -std=c++98

(usually to included pxd files, e.g. src/sage/libs/linbox/linbox.pxd)
but this apparently doesn't work for modules with additional
extra_compile_args in src/module_list.py, so you can (or have to) add it
there.

> I called CFLAGS="$CFLAGS -std=gnu++98" make (which might be the culprit;
> I know too little about how the building process works ...), let it
> compile for a while and switched back to just "make -j4" by interrupting
> and restarting. This lets the compilation of the modules finish, but...

Doesn't work for me (yet) with vanilla FSF GCC 6.1.0, I'm still getting
errors despite of passing '-std=c++98' (or '-std=gnu++98',
'-fpermissive'), e.g. in sage/matrix/matrix_modn_sparse, but not all
that use LinBox (some of them compile when '-std=c++98' gets added).

Perhaps something for a cythonist, or some GCC bug that got fixed in
Arch's version as the module did compile for you?

> ... then I get a segfault (last few lines are at
> http://pastebin.com/CBXhNN9P -- and I uploaded my full install.log to
> http://benjamin-hackl.at/downloads/behackl-20160629.install.log).
>
> Unfortunately, the reason for this is not that obvious to me---does
> anyone have an idea or suggestions (besides downgrading my gcc...)? :-|

No idea. (All I can see is that it happens early when trying to
initialize libsingular.)


-leif

>
> Benjamin

[leif]

leif wrote:

> Benjamin Hackl wrote:
>> I have a very similar setup (gcc 6.1.1 20160602 on Arch Linux), and I'm
>> struggling quite hard to build 7.2:
>>

> [SNIP]

>
>> The next failure then occurs when the Sage library modules are compiled:
>> as I couldn't find out how to add '-std=gnu++98' for a single module,
>
> The "clean" way is to add
>
> # distutils: extra_compile_args = -std=c++98
>
> (usually to included pxd files, e.g. src/sage/libs/linbox/linbox.pxd)
> but this apparently doesn't work for modules with additional
> extra_compile_args in src/module_list.py, so you can (or have to) add it
> there.
>
>
>> I called CFLAGS="$CFLAGS -std=gnu++98" make (which might be the culprit;
>> I know too little about how the building process works ...), let it
>> compile for a while and switched back to just "make -j4" by interrupting
>> and restarting. This lets the compilation of the modules finish, but...
>
> Doesn't work for me (yet) with vanilla FSF GCC 6.1.0, I'm still getting
> errors despite of passing '-std=c++98' (or '-std=gnu++98',
> '-fpermissive'), e.g. in sage/matrix/matrix_modn_sparse, but not all
> that use LinBox (some of them compile when '-std=c++98' gets added).
>
> Perhaps something for a cythonist, or some GCC bug that got fixed in
> Arch's version as the module did compile for you?

Nope, just Cython weirdness, it simply got compiled as C++.

The following works for me to let the whole Sage library build with GCC
6.1 (without setting any flags in the environment):

diff --git a/src/module_list.py b/src/module_list.py
index a49ed36..8441106 100644
--- a/src/module_list.py
+++ b/src/module_list.py
@@ -926,7 +926,7 @@ ext_modules = [
libraries = ['ntl', 'linbox', 'givaro', 'mpfr', 'gmpxx',
'gmp'] + cblas_libs,
library_dirs = cblas_library_dirs,
include_dirs = cblas_include_dirs,
- extra_compile_args = ['-DDISABLE_COMMENTATOR'] +
givaro_extra_compile_args),
+ extra_compile_args = ['-std=c++98',
'-DDISABLE_COMMENTATOR'] + givaro_extra_compile_args),

Extension('sage.matrix.matrix_modn_dense_double',
sources = ['sage/matrix/matrix_modn_dense_double.pyx'],
@@ -934,7 +934,7 @@ ext_modules = [
libraries = ['ntl', 'linbox', 'givaro', 'mpfr', 'gmpxx',
'gmp'] + cblas_libs,
library_dirs = cblas_library_dirs,
include_dirs = cblas_include_dirs,
- extra_compile_args = ["-D_XPG6", "-DDISABLE_COMMENTATOR"]
+ extra_compile_args = ['-std=c++98', "-D_XPG6",
"-DDISABLE_COMMENTATOR"]
+ m4ri_extra_compile_args + givaro_extra_compile_args),

Extension('sage.matrix.matrix_modn_sparse',
diff --git a/src/sage/libs/linbox/linbox.pxd
b/src/sage/libs/linbox/linbox.pxd
index 0afd7bf..87a5e79 100644
--- a/src/sage/libs/linbox/linbox.pxd
+++ b/src/sage/libs/linbox/linbox.pxd
@@ -1,3 +1,6 @@
+# distutils: language = c++
+# distutils: extra_compile_args = -std=c++98
+
from sage.libs.gmp.types cimport mpz_t

include 'sage/modules/vector_modn_sparse_h.pxi'
diff --git a/src/sage/matrix/matrix_modn_sparse.pxd
b/src/sage/matrix/matrix_modn_sparse.pxd
index 5273ec3..14a98e7 100644
--- a/src/sage/matrix/matrix_modn_sparse.pxd
+++ b/src/sage/matrix/matrix_modn_sparse.pxd
@@ -1,3 +1,5 @@
+# distutils: language = c
+
cimport matrix_sparse

include 'sage/modules/vector_modn_sparse_h.pxi'

>> ... then I get a segfault (last few lines are at
>> http://pastebin.com/CBXhNN9P -- and I uploaded my full install.log to
>> http://benjamin-hackl.at/downloads/behackl-20160629.install.log).
>>
>> Unfortunately, the reason for this is not that obvious to me---does
>> anyone have an idea or suggestions (besides downgrading my gcc...)? :-|
>
> No idea. (All I can see is that it happens early when trying to
> initialize libsingular.)

Now the same situation here; Sage segfaults (in initializing
libsingular), as does './sage --singular'.

So we'd have to take a closer look at the Singular package, which
unfortunately(?) is kind of obsolete at the moment (recently got
downgraded from 4.x to 3.1.7p1 again.)

Seems while it /compiles/ in C++14 mode with a trivial syntactic fix,
the resulting code is no longer functional. I'll try to (re)build it
with '-std=c++11' or '-std=c++98'...


-leif

[leif]

Results in the same, in both cases. (You can rebuild Singular with
'-std=c++98' by typing 'env CXX="g++ -std=c++98" ./sage -f singular';
this "works" in contrast to setting CXXFLAGS which aren't consistently
used or dropped in some places IIRC.)


-leif

[Volker Braun]

I made https://trac.sagemath.org/ticket/20926 to deal with gcc6 / c++11 fallout