Opened 10 years ago

Closed 6 years ago

#11162 closed enhancement (duplicate)

print warning if no C compiler found

Reported by: jhpalmieri Owned by:
Priority: minor Milestone: sage-duplicate/invalid/wontfix
Component: scripts Keywords:
Cc: drkirkby Merged in:
Authors: Reviewers: John Palmieri
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by drkirkby)

If no C compiler is found, print a warning the first time you run "sage", "sage -cython", etc.

Attachments (1)

trac_11162-no-cc.patch (4.1 KB) - added by jhpalmieri 10 years ago.
scripts repo

Download all attachments as: .zip

Change History (20)

comment:1 Changed 10 years ago by jhpalmieri

  • Status changed from new to needs_review

comment:2 Changed 10 years ago by jhpalmieri

  • Cc drkirkby added

comment:3 Changed 10 years ago by drkirkby

We already have a script which checks the type of C compiler. I think that can either be used as-is, or with a small modification. The script is:

  $SAGE_ROOT/local/bin/testcc.sh

I think it would be better to call that, rather than create another script.

drkirkby@hawk:~/sage-4.7.alpha3$ export CC=ls              # Not a valid C compiler. 
drkirkby@hawk:~/sage-4.7.alpha3$ local/bin/testcc.sh $CC
drkirkby@hawk:~/sage-4.7.alpha3$ export CC=gcc
drkirkby@hawk:~/sage-4.7.alpha3$ local/bin/testcc.sh $CC
GCC
drkirkby@hawk:~/sage-4.7.alpha3$ export CC=cc
drkirkby@hawk:~/sage-4.7.alpha3$ local/bin/testcc.sh $CC
Sun_Studio
drkirkby@hawk:~/sage-4.7.alpha3$ local/bin/testcc.sh $CC
drkirkby@hawk:~/sage-4.7.alpha3$ export CC=fdddffdfdfdfdfd        # Non existent compiler. 
local/bin/testcc.sh: line 114: fdddffdfdfdfdfd: not found
drkirkby@hawk:~/sage-4.7.alpha3$ 

comment:4 follow-up: Changed 10 years ago by jhpalmieri

I think it would be better if testcc.sh exited with a nonzero status if there were a problem, but I don't know how to do that. The culprit is the line

${CC_LOCAL} -E $TESTFILE | grep '^[A-Z]' | sed 's/ //g'

This returns the exit code for the last command in the pipeline, rather than the exit status for "${CC_LOCAL} ...", which is what we care about.

As it stands, though, if I use testcc.sh, I can see whether it outputs anything; if there is no output, there must not be a valid C compiler.

So now that you've pointed it out, I think that testcc.sh is a good tool to check whether the C compiler works, and I've incorporated it into the sage-check-cc script. That is, sage-check-cc is acting like a front-end to testcc.sh, taking care of printing a warning and caching the appropriate information. If you want all of this combined into a single script, we could do that instead, I suppose.

Changed 10 years ago by jhpalmieri

scripts repo

comment:5 in reply to: ↑ 4 Changed 10 years ago by drkirkby

Replying to jhpalmieri:

I think it would be better if testcc.sh exited with a nonzero status if there were a problem, but I don't know how to do that. The culprit is the line

${CC_LOCAL} -E $TESTFILE | grep '^[A-Z]' | sed 's/ //g'

I agree. I'll see if I can modify it. I originally created the script and understood it fully. Leif made some modifications, so now I'm not sure if I understand it fully. But it should be possible to make this exit with a non-zero code if there's not a compiler.

Dave

comment:6 Changed 10 years ago by drkirkby

See #11169 for a revised version of testcc.sh which exit with an exit code of 1 in case of a problem. That should allow a simpler version of this patch.

Dave

comment:7 Changed 10 years ago by drkirkby

  • Description modified (diff)
  • Summary changed from print warning if no c compiler found to print warning if no C compiler found

Should a C++ compiler be checked for too? Certainly rebuilding the Sage library needs a C++ compiler, as running:

drkirkby@hawk:~/sage-4.7.alpha3$ ./sage -ba | grep g++ 

produces a lot of output. (You need to insert a "y", as the script asks for that, though you can't see it because of the grep statement)

g++ -shared build/temp.solaris-2.11-i86pc-2.6/sage/symbolic/function.o -L/export/home/drkirkby/sage-4.7.alpha3/local/lib -L/export/home/drkirkby/sage-4.7.alpha3/local/lib -lcsage -lpynac -lgmp -lstdc++ -lntl -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/sage/symbolic/function.so
g++ -shared build/temp.solaris-2.11-i86pc-2.6/sage/symbolic/pynac.o -L/export/home/drkirkby/sage-4.7.alpha3/local/lib -L/export/home/drkirkby/sage-4.7.alpha3/local/lib -lcsage -lpynac -lgmp -lgsl -lstdc++ -lntl -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/sage/symbolic/pynac.so
g++ -shared build/temp.solaris-2.11-i86pc-2.6/sage/rings/polynomial/pbori.o -L/export/home/drkirkby/sage-4.7.alpha3/local/lib -L/export/home/drkirkby/sage-4.7.alpha3/local/lib -lcsage -lpolybori -lpboriCudd -lgroebner -lgd -lpng12 -lm4ri -lstdc++ -lntl -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/sage/rings/polynomial/pbori.so
g++ -shared build/temp.solaris-2.11-i86pc-2.6/sage/symbolic/expression.o -L/export/home/drkirkby/sage-4.7.alpha3/local/lib -L/export/home/drkirkby/sage-4.7.alpha3/local/lib -lcsage -lpynac -lgmp -lstdc++ -lntl -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/sage/symbolic/expression.so
drkirkby@hawk:~/sage-4.7.alpha3$ 

This is making me think we should perhaps check for a C++ compiler too, but I'm not sure.

A basic install of an operating system might well have a C compiler, but not a C++ compiler.

Dave

comment:8 Changed 9 years ago by jdemeyer

  • Status changed from needs_review to needs_info

Obvious question: why should we warn that a user doesn't have a C compiler? Such a user must have downloaded a binary version of Sage and is very unlikely to ever run sage -b or anything requiring a C compiler.

comment:9 follow-up: Changed 9 years ago by jhpalmieri

Because you need a C compiler to run code in a %cython block in the notebook, for example, or to attach a user-written .pyx or .sagex file. Cython is one of the attractive features of Sage, and for Sage to work as documented, you need a C compiler.

comment:10 in reply to: ↑ 9 Changed 9 years ago by jdemeyer

Replying to jhpalmieri:

Because you need a C compiler to run code in a %cython block in the notebook, for example, or to attach a user-written .pyx or .sagex file.

Then simply print an error when the user tries to do one of these things. I don't think we should warn in advance "just in case".

comment:11 follow-up: Changed 9 years ago by jhpalmieri

Okay, so when do we need to print an error?

  • when running sage -ba
  • when running sage -b if a Cython file has been modified
  • when running sage --cython ...
  • when running sage --upgrade ...
  • when running sage -i ... or sage -f ...
  • while running sage, when attaching a pyx or spyx file
  • while running the sage notebook, when evaluating a %cython block

Anything else?

It seems like it might actually be less intrusive if you print a warning once, the first time Sage is run, than if you raise an error whenever any of these are attempted. It also looks more complicated to write a patch to catch all of the possible cases.

But I don't have a strong opinion about this. I agree with the "minor" priority for this ticket...

comment:12 Changed 9 years ago by kcrisman

See also #13533. I feel like these are at cross-purposes, though I can't say exactly why.

comment:13 Changed 9 years ago by jdemeyer

needs_work also for a different reason: you should actually compile a program instead of simply running the preprocessor (which is what testcc.sh does).

Otherwise this will lead to false positives of users having a gcc program but no assembler or linker. In the light of the gcc spkg, this is quite plausible.

comment:14 in reply to: ↑ 11 Changed 9 years ago by jdemeyer

Replying to jhpalmieri:

It seems like it might actually be less intrusive if you print a warning once, the first time Sage is run, than if you raise an error whenever any of these are attempted. It also looks more complicated to write a patch to catch all of the possible cases.

I feel like printing a warning once is essentially equivalent to not printing a warning at all. Very likely, it will go unnoticed.

So my personal feeling for this ticket is "wontfix". It looks too complicated to do it right, and the gain is marginal.

comment:15 Changed 9 years ago by jhpalmieri

So my personal feeling for this ticket is "wontfix". It looks too complicated to do it right, and the gain is marginal.

That's okay with me. Or we can leave it open and hope someone figures out a good way to do it right, and puts in the time to implement it. (That's not going to be me.)

comment:16 Changed 8 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:17 Changed 7 years ago by jdemeyer

  • Milestone changed from sage-6.1 to sage-wishlist

comment:18 Changed 6 years ago by jdemeyer

  • Authors John Palmieri deleted
  • Milestone changed from sage-wishlist to sage-duplicate/invalid/wontfix
  • Reviewers set to John Palmieri
  • Status changed from needs_info to positive_review

Close as "wontfix" and/or "duplicate" of #13529.

comment:19 Changed 6 years ago by vbraun

  • Resolution set to duplicate
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.