Sage 6.4.1 released

[Volker Braun]

Get the updated "master" git branch or source tarball:  http://sage.sagedev.org/home/release/sage-6.4.1.tar.gz

Mini-changelog:

76b4ac4 Updated Sage version to 6.4.1

f045b63 Trac #15316: Make gf2x respect SAGE_FAT_BINARY and use --libdir

217c188 Trac #17346: The sage-bdist script is not executable

473474a Trac #17349: R fails with version `GOMP_4.0' not found

bac8b26 Trac #17375: Maxima should not need a working C compiler to run

21d9db2 Updated Sage version to 6.4

[kcrisman]

Get the updated "master" git branch or source tarball:  http://sage.sagedev.org/home/release/sage-6.4.1.tar.gz

Downloaded the tarball, set SAGE_FAT_BINARY="yes" and 

mkdir common

mkdir common/.deps

config.status: executing default commands

make[4]: *** [stage1-bubble] Error 2

make[3]: *** [all] Error 2

real 2m37.652s

user 0m36.100s

sys 0m33.567s

************************************************************************

Error installing package gcc-4.9.2

************************************************************************

This is on OS X 10.7.5, Intel Core i7 chip. 

[kcrisman]

mkdir common

mkdir common/.deps

config.status: executing default commands

make[4]: *** [stage1-bubble] Error 2

make[3]: *** [all] Error 2

real 2m37.652s

user 0m36.100s

sys 0m33.567s

************************************************************************

Error installing package gcc-4.9.2

************************************************************************

pkg log at http://sage.math.washington.edu/home/kcrisman/gcc-4.9.2.log but I don't think it will reveal much. 

[Francois Bissey]

Hum… 10.7.5, what version of clang do you have. I will inspect the log in more depth
but I am wondering if your compiler is not sufficient to build gcc 4.9.x. In that case
you may need a stepping stone with another gcc first - 4.7.x would be ok.

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 http://groups.google.com/group/sage-release.
> For more options, visit https://groups.google.com/d/optout.

[Francois Bissey]

It would be easier if you were producing a log while building at -j1 it makes the log
easier, the error is here and it is mighty suspicious:
g++ -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -g -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../src/libcpp/charset.c
g++ -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -g -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -c -o directives.o -MT directives.o -MMD -MP -MF .deps/directives.Tpo ../../src/libcpp/directives.c
g++ -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -g -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include -c -o directives-only.o -MT directives-only.o -MMD -MP -MF .deps/directives-only.Tpo ../../src/libcpp/directives-only.c
checking for putc_unlocked... cc1plus: error: unrecognized command line option "-Wno-narrowing"
cc1plus: error: unrecognized command line option "-Wno-narrowing"
make[6]: *** [directives.o] Error 1
make[6]: *** Waiting for unfinished jobs....
make[6]: *** [directives-only.o] Error 1
cc1plus: error: unrecognized command line option "-Wno-narrowing"
make[6]: *** [charset.o] Error 1
make[5]: *** [all-stage1-libcpp] Error 2
make[5]: *** Waiting for unfinished jobs....

But I would definitely would like a serial log so I am sure where we are.

François

[Jeroen Demeyer]

On 2014-11-25 06:54, Francois Bissey wrote:
> It would be easier if you were producing a log while building at -j1

Absolutely. It's very hard to read logs of parallel builds since the
actual error could be essentially anywhere in the log.

[Volker Braun]

Can you try again? It worked with 6.4 and we didn't change anything that pertains to gcc in 6.4.1.

[kcrisman]

Can you try again? It worked with 6.4 and we didn't change anything that pertains to gcc in 6.4.1.

I tried twice, same thing.  I wonder if the fact that I have been just upgrading time by time is why my other installations are working okay?  I'm sure it has something to do with the 4.9.x series

configure: updating cache ./config.cache

configure: creating ./config.status

config.status: creating Makefile

config.status: creating config.h

config.status: executing depdir commands

mkdir .deps

g++  -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include  -g  -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long  -fno-exceptions -fno-rtti -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include   -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../src/libcpp/charset.c

cc1plus: error: unrecognized command line option "-Wno-narrowing"

make[6]: *** [charset.o] Error 1

make[5]: *** [all-stage1-libcpp] Error 2

make[4]: *** [stage1-bubble] Error 2

make[3]: *** [all] Error 2

real 1m18.941s

user 0m27.656s

sys 0m25.307s

************************************************************************

Error installing package gcc-4.9.2

************************************************************************

Full serial log at the same location as before (appended to the previous one, I guess this is just how Sage logs work, you'll have to search for the 2nd or 3rd run-through).  I note that while it checks a lot of options for existence

checking whether /usr/bin/clang supports -W... yes

checking whether /usr/bin/clang supports -Wall... yes

checking whether /usr/bin/clang supports -Wnarrowing... yes

checking whether /usr/bin/clang supports -Wwrite-strings... yes

checking whether /usr/bin/clang supports -Wmissing-format-attribute... yes

checking whether /usr/bin/clang supports -Wstrict-prototypes... yes

checking whether /usr/bin/clang supports -Wmissing-prototypes... yes

checking whether /usr/bin/clang supports -Wold-style-definition... yes

checking whether /usr/bin/clang supports -Wc++-compat... yes

checking whether /usr/bin/clang supports -pedantic -Wlong-long... yes

checking whether /usr/bin/clang supports -fno-exceptions... yes

checking whether /usr/bin/clang supports -fno-rtti... yes

it doesn't check for this particular one, only -Wnarrowing.  And https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html has no mention even of -Wnarrowing, only at https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html where it says

With -std=c++11, -Wno-narrowing suppresses for non-constants the diagnostic required by the standard. 

Interestingly, in the logs for my standard installation (currently also with gcc 4.9.2) it has plenty of these flags with no worries.  But I think the reason is because in the one in Sage,

C compiler: gcc

C compiler version:

Using built-in specs.

COLLECT_GCC=/Users/karl.crisman/Downloads/sage/local/bin/gcc

while "from scratch", as François suspected,

C compiler: /usr/bin/clang

C compiler version:

Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)

I wonder if there are other problems lurking there.  I don't see a place in spkg-install to put extra flags, nor am I sure what the exact syntax would be for that.

[Volker Braun]

A recent clang is supposed to understand -Wno-narrowing. Are you sure your xcode/command line tools are up to date?

[kcrisman]

A recent clang is supposed to understand -Wno-narrowing. Are you sure your xcode/command line tools are up to date?

Yes.  Xcode 4.6.3 is the last that runs on OS X 10.7. 

I suspect that the 4.9 series is the problem here - not a bug, just not compatible.  Downloading 6.4.beta6 to test this hypothesis.

Alternately, is there a way for me to pass -Wnarrowing (part of -Wall) back in so I can keep trying this?

[kcrisman]

A recent clang is supposed to understand -Wno-narrowing. Are you sure your xcode/command line tools are up to date?

Yes.  Xcode 4.6.3 is the last that runs on OS X 10.7. 

I suspect that the 4.9 series is the problem here - not a bug, just not compatible.  Downloading 6.4.beta6 to test this hypothesis.

A partial (parallel) log is at http://sage.math.washington.edu/home/kcrisman/gcc-4.7.3.p1.log but no problems, and (interestingly) the same option already occurs there, so I am baffled now.

Ah, I think the problem is that /usr/bin/clang is the one doing it in 4.7.3, while in 4.9.2 it's g++ doing that.  I don't know how to check what that is but presumably it is i686-apple-darwin11-llvm-g++-4.2

So maybe, when clang is present, we need to have that doing the compiling of g++ stuff too in gcc-4.9.2?

[kcrisman]

I suspect that the 4.9 series is the problem here - not a bug, just not compatible.  Downloading 6.4.beta6 to test this hypothesis.

A partial (parallel) log is at http://sage.math.washington.edu/home/kcrisman/gcc-4.7.3.p1.log but no problems, and (interestingly) the same option already occurs there, so I am baffled now.

Ah, I think the problem is that /usr/bin/clang is the one doing it in 4.7.3, while in 4.9.2 it's g++ doing that.  I don't know how to check what that is but presumably it is i686-apple-darwin11-llvm-g++-4.2

So maybe, when clang is present, we need to have that doing the compiling of g++ stuff too in gcc-4.9.2?

In particular, I get

$ ls -l /usr/bin/g++

lrwxr-xr-x  1 root  wheel  12 Oct  8  2013 /usr/bin/g++ -> llvm-g++-4.2

$ ls -l /usr/bin/gcc

lrwxr-xr-x  1 root  wheel  12 Oct  8  2013 /usr/bin/gcc -> llvm-gcc-4.2

$ ls -l /usr/bin/clang

-rwxr-xr-x  1 root  wheel  26311808 Oct  8  2013 /usr/bin/clang

So in sage-env  maybe this code should be updated.

# Set the C and C++ compilers

if [ -z "$CC" ]; then

    # On OS X 10.7 (Lion) or later when building GCC, use clang as

    # default C compiler as some older versions of XCode 4 ship broken

    # versions of GCC which fail to bootstrap GCC-4.6.3.

    # See http://trac.sagemath.org/sage_trac/ticket/12820

    if [ "$SAGE_BUILD_TOOLCHAIN" = yes ] && [ "$UNAME" = Darwin ] && [ `uname -r | cut -d.$

        CC=`which clang 2>/dev/null`

    fi

fi

if [ -z "$CC" ]; then

    CC=gcc

fi

if [ -z "$CXX" ]; then

    CXX=g++

fi

I'm going to try with CXX=/usr/bin/clang and see what happens.

[kcrisman]

Ah, I think the problem is that /usr/bin/clang is the one doing it in 4.7.3, while in 4.9.2 it's g++ doing that.  I don't know how to check what that is but presumably it is i686-apple-darwin11-llvm-g++-4.2

So maybe, when clang is present, we need to have that doing the compiling of g++ stuff too in gcc-4.9.2?

I'm going to try with CXX=/usr/bin/clang and see what happens.

*Different* error, anyway!  It certainly gets further, and doesn't complain about -Wno-narrowing.

/usr/bin/clang  -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include  -g  -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long  -fno-exceptions -fno-rtti -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include   -c -o init.o -MT init.o -MMD -MP -MF .deps/init.Tpo ../../src/libcpp/init.c

/usr/bin/clang  -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include  -g  -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long  -fno-exceptions -fno-rtti -I../../src/libcpp -I. -I../../src/libcpp/../include -I../../src/libcpp/include   -c -o lex.o -MT lex.o -MMD -MP -MF .deps/lex.Tpo ../../src/libcpp/lex.c

../../src/libcpp/lex.c:1487:3: error: must use 'enum' tag to refer to type 'raw_str_phase'

  raw_str_phase phase = RAW_STR_PREFIX;

  ^

  enum 

1 error generated.

make[6]: *** [lex.o] Error 1

make[5]: *** [all-stage1-libcpp] Error 2

make[4]: *** [stage1-bubble] Error 2

make[3]: *** [all] Error 2

real 1m15.380s

user 0m28.285s

sys 0m25.846s

************************************************************************

Error installing package gcc-4.9.2

************************************************************************ 

Surveying http://comments.gmane.org/gmane.comp.gcc.bugs/413564 it seems like we need to set clang++ instead, okay, I didn't even know that existed... trying AGAIN.

[kcrisman]

Surveying http://comments.gmane.org/gmane.comp.gcc.bugs/413564 it seems like we need to set clang++ instead, okay, I didn't even know that existed... trying AGAIN.

Still going but looks good so far.  See http://trac.sagemath.org/ticket/17397 - I've made this a blocker since it prevents compiling from scratch. 

[Justin C. Walker]

> On Nov 23, 2014, at 11:58, Volker Braun <vbrau...@gmail.com> wrote:
>
> Get the updated "master" git branch or source tarball: http://sage.sagedev.org/home/release/sage-6.4.1.tar.gz

Just getting back to building sage. On 10.10.1 (Xcode 6.1), I get this error when building the gcc (4.9.2) package:

The directory that should contain system headers does not exist:
/usr/include

I probably missed something in the Yosemite discussions, or my Xcode install is slightly borked. I did a quick check of the lists and did not see this particular error mentioned. Any clues?

The install and gcc package logs are on sage.math, ~justin/logs.

Thanks!

--
Justin C. Walker
Curmudgeon at Large
Director
Institute for the Enhancement of the Director's Income
--
Build a man a fire and he'll be warm
for a night.
Set a man on fire and he'll be warm
for the rest of his life.

[François Bissey]

I think you need to install/update xcode cli tools. For some reasons
it doesn't happens automatically when you upgrade the rest.
I think the command
"xcode-select install"
will get you there.

Francois

[Justin C. Walker]

> On Nov 26, 2014, at 16:14, François Bissey <francoi...@canterbury.ac.nz> wrote:
>
> I think you need to install/update xcode cli tools. For some reasons
> it doesn't happens automatically when you upgrade the rest.
> I think the command
> "xcode-select install"
> will get you there.

Ow! Grumble…I was able to build a lot of stuff with my current installation (readline, gap, gp, …), so I didn’t catch on.

Thanks for the tip. That worked (I think): still building gcc, but at least “/usr/include” has put in an appearance.

Justin

[kcrisman]

Bad news for old Mac fans... Is gcc 4.0.1 sufficient to build gcc 4.9.2?  I couldn't find an explicit statement on the internet. I was able to successfully compile earlier betas for Sage 6.4, so I have a feeling that the switch to 4.9.2 is why gcc won't build for me now on OS X 10.4 PPC.

See http://sage.math.washington.edu/home/kcrisman/gcc-4.9.2.config.log and http://sage.math.washington.edu/home/kcrisman/gcc-4.9.2.log  Relevant sections, I think:

checking for powerpc-apple-darwin8.11.0-gcc... /Users/student/Desktop/sage-6.4.1/local/var/tmp/sage/build/gcc-4.9.2/gcc-build/./gcc/xgcc -B/Users/student/Desktop/sage-6.4.1/local/var/tmp/sage/build/gcc-4.9.2/gcc-build/./gcc/ -B/Users/student/Desktop/sage-6.4.1/local/powerpc-apple-darwin8.11.0/bin/ -B/Users/student/Desktop/sage-6.4.1/local/powerpc-apple-darwin8.11.0/lib/ -isystem /Users/student/Desktop/sage-6.4.1/local/powerpc-apple-darwin8.11.0/include -isystem /Users/student/Desktop/sage-6.4.1/local/powerpc-apple-darwin8.11.0/sys-include   
checking for suffix of object files... configure: error: in `/Users/student/Desktop/sage-6.4.1/local/var/tmp/sage/build/gcc-4.9.2/gcc-build/powerpc-apple-darwin8.11.0/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[5]: *** [configure-stage1-target-libgcc] Error 1
make[5]: Target `all-stage1' not remade because of errors.
make[4]: *** [stage1-bubble] Error 2
make[4]: Target `stage3-bubble' not remade because of errors.
make[3]: *** [all] Error 2

configure:4990: g++ -o conftest    -static-libstdc++ -static-libgcc conftest.cpp  >&5
powerpc-apple-darwin8-g++-4.0.1: unrecognized option '-static-libstdc++'
conftest.cpp:11:2: error: #error -static-libstdc++ not implemented
configure:4990: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
| 
| #if (__GNUC__ < 4) || (__GNUC__ == 4 && __GNUC_MINOR__ < 5)
| #error -static-libstdc++ not implemented
| #endif
| int main() {}
configure:4994: result: no

Maybe there is some dumb way to fix this like there was for #17397?  http://stackoverflow.com/a/26826240/782821 suggests one would need gcc 4.2 first but I don't know if that's true.  I do have /usr/lib/libstdc++.6.0.4.dylib but http://www.trilithium.com/johan/2005/06/static-libstdc/ implies perhaps this was not implemented lo these many years ago - perhaps as recently as 4.5? http://gcc.gnu.org/gcc-4.5/changes.html

But I don't understand what that has to do with the error

configure: error: cannot compute suffix of object files: cannot compile

[kcrisman]

Bad news for old Mac fans... Is gcc 4.0.1 sufficient to build gcc 4.9.2?  I couldn't find an explicit statement on the internet. I was able to successfully compile earlier betas for Sage 6.4, so I have a feeling that the switch to 4.9.2 is why gcc won't build for me now on OS X 10.4 PPC.

Incidentally, though I don't think I'd want to do this long-term, I think I might be interested in pulling off one final set of binaries for PPC for Sage 6.4.1 if it were not too hard to go back to commit 9f3a73e9 in build/pkgs/gcc/ only - would that screw anything up?

[François Bissey]

I think we did go to 4.9.1 (initially) purely to support yosemite. So I don't
think that would break anything.
gcc 4.0.1 is definitely too old to build 4.9.x. You have need a stepping stone
at 4.6 or 4.7 (probably not 4.8).

Francois

[kcrisman]

> Incidentally, though I don't think I'd want to do this long-term, I think I
> might be interested in pulling off one final set of binaries for PPC for
> Sage 6.4.1 if it were not too hard to go back to commit 9f3a73e9 in
> build/pkgs/gcc/ only - would that screw anything up?
I think we did go to 4.9.1 (initially) purely to support yosemite. So I don't
think that would break anything.

Yes, that's what I thought.  I don't know how much this is integrated into other stuff, though.

 

gcc 4.0.1 is definitely too old to build 4.9.x. You have need a stepping stone
at 4.6 or 4.7 (probably not 4.8).

Okay, that's what I thought.  Nuts. 

[kcrisman]

The problem is one needs a working Sage to get at the fix-spkg-checksums or whatever it's called, plus to have a working git to revert anything needed to revert there... sigh.  Not today, anyway. 

[François Bissey]

Would definitely prepare source on another computer.

Francois

[Jeroen Demeyer]

On 2014-12-04 21:03, François Bissey wrote:
> gcc 4.0.1 is definitely too old to build 4.9.x.

Are you sure about this statement or are you just guessing?

[Francois Bissey]

99% sure. The C++ compiler needs some elements of C++11. I am fairly sure that
nothing below 4.2 will build gcc 4.9, but I think the barrier is either 4.5 or 4.6.
I would to check but I think I build it with 4.6 (on AIX 5.3).
François

[Volker Braun]

On Friday, December 5, 2014 10:40:46 AM UTC, François wrote:

The C++ compiler needs some elements of C++11.

In theory everything should work with a C++98 compiler only. But it needs to not bail out when encountering options to turn off warnings that it doesn't understand. Really, if you don't know what narrowing is then "-Wno-narrowing" is clearly a no-op. But older gcc's raise an error here.

[kcrisman]

The C++ compiler needs some elements of C++11.

In theory everything should work with a C++98 compiler only. But it needs to not bail out when encountering options to turn off warnings that it doesn't understand. Really, if you don't know what narrowing is then "-Wno-narrowing" is clearly a no-op. But older gcc's raise an error here.

I believe that François is correct about this, though.  (The narrowing thing was a different discussion, which should be fixed by the clang++ thing.) 

> > The problem is one needs a working Sage to get at the fix-spkg-checksums or 
> > whatever it's called, plus to have a working git to revert anything needed 
> > to revert there... sigh.  Not today, anyway. 

> Would definitely prepare source on another computer. 

Oh yeah, good point.

[Francois Bissey]

Don’t remember where I got the C++11 from but Volker is correct according to
the gcc folks themselves:
https://gcc.gnu.org/install/prerequisites.html

[Justin C. Walker]

On Nov 23, 2014, at 11:58 , Volker Braun wrote:

> Get the updated "master" git branch or source tarball:
> http://sage.sagedev.org/home/release/sage-6.4.1.tar.gz

Built from the tarball, w/o problems. All tests ('ptestlong') passed.
OS X, 10.6.8 (Dual 6-core Xeons) and 10.10.1 (Quad-core Core i7).

--
Justin C. Walker, Curmudgeon-At-Large

Institute for the Enhancement of the Director's Income

--------
When LuteFisk is outlawed,
Only outlaws will have LuteFisk
--------

[kcrisman]

Don’t remember where I got the C++11 from but Volker is correct according to
the gcc folks themselves:
https://gcc.gnu.org/install/prerequisites.html

> In theory everything should work with a C++98 compiler only. But it needs to not bail out when encountering options to turn off warnings that it doesn't understand. Really, if you don't know what narrowing is then "-Wno-narrowing" is clearly a no-op. But older gcc's raise an error here. 

I asked earlier whether it would work to do

CXXFLAGS="-Wnarrowing" make

or something like that, but no one answered me.  But in this case (gcc 4.0.1) I would have to somehow remove the following option

powerpc-apple-darwin8-g++-4.0.1: unrecognized option '-static-libstdc++'

and I don't know how to do that.