Opened 12 years ago

Last modified 9 years ago

#7818 closed defect

Update sage-env — at Version 11

Reported by: drkirkby Owned by: drkirkby
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: porting Keywords:
Cc: was, jsp Merged in:
Authors: David Kirkby Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by drkirkby)

This is an update to the sage-env file. It should allow a much improved build process, simplifying the code in spkg install files, as much of it will be taken care of. The code will also be more portable.

  • Little or no need for any SAGE64 rubbish in any spkg-install files. The appropriate flag to build 64-bit code is added if SAGE64 is set to use.
  • No need to add -Wall or -g, as these are added by default.
  • GNU specific compiler options can be replaced by variables with similar names to the GNU ones, making substitution a relatively easy task.
  • Will enable code to be much more portable.

The changes mainly affect the 3 variables for compiler flags - CFLAGS, CXXFLAGS and FCFLAGS.

The user may set CFLAGS, CXXFLAGS and FCFLAGS, but the following will be appended.

General flags

  • The -g option is added to enable debugging unless SAGE_DEBUG is set to "no".
  • -Wall is added for gcc, g++ and gfortran.

64-bit Flags

If SAGE64 is "yes"

  • -m64 is added for GCC
  • -m64 is added for Sun Studio
  • -q64 is added for IBM's compiler on AIX
  • +DA2.OW is added for the PA-RISC architecture on HP-UX
  • +DD64 is added for the Itanium architecture on HP-UX

A variable CFLAG64 is set to the correct option for building 64-bit binaries with the C compiler. So if -m64 is replaced by $CFLAG64, the code will work on any C compiler.

(Some compilers may require a different option for C and C++ files. The names CXXFLAG64 and FCFLAG64 are reserved for this, but its not suggested they are used now)

C++ library flags

Due to changes in the C++ standard, it is impossible for compiler vendors to distribute a C++ runtime library which is both compatible with the old standard and the new one. Both HP and Sun use the older library by default, and need a switch added to enable the newer libraries, which more closely follow the latest C++ standard. See:

http://developers.sun.com/solaris/articles/cmp_stlport_libCstd.html

http://docs.hp.com/en/14487/faq.htm

Therefore

  • If the compiler is Sun Studio, library=stlport4 is added to CXXFLAGS.
  • If the Compiler is HP's on HP-UX, the option -AA is added to CXXFLAGS.

Shared Library Flags

Five new variables are set in sage-env. These are for building shared libraries and take on names very similar to the GNU names for the flags.

Flag nameValue with GCCValue with Sun Studio
FPIC_FLAG-fPIC-xcode=pic32
SHARED_FLAG-shared-G
SONAME_FLAG-soname-h

A reviewer may notice two further variable names used. These options can be linker dependent and will be finalized once some code to detect the linker is in place.

Extension for shared libraries

Many systems have to be linked against a library, who extension changes depending on what plaform one is using. A variable 'SHARED_LIBRARY_EXTENSION' is set to one of the following:

PlatformValue
AIXa
Cygwindll
HP-UXsl
OS Xdylib
Anything else (Linux, Solaris etc)so

Change History (11)

comment:1 Changed 12 years ago by drkirkby

  • Status changed from new to needs_review

comment:2 Changed 12 years ago by drkirkby

  • Authors set to David Kirkby

comment:3 Changed 12 years ago by drkirkby

Just to make the point, -m64 in sage should not need to be replaced by 'CLFAG64' in general. In 99% of cases, simply removing all the -m64's that litter Sage will do the trick, as the right option will be added automatically.

In some cases, it may be necessary to keep such a flag on linking. In those rare cases (ECL is the only example I can think of), then use CFLAG64 instead of -m64. But this will allow 99% of the -m64's to be removed and forgotten about, as they will be added only where necessary.

comment:4 Changed 12 years ago by drkirkby

Oopsn, I mean in rare cases, -m64 might need to be replaced by $CFLAG64.

comment:5 Changed 12 years ago by jhpalmieri

Should line 87 be changed from

echo "NAME_OF_ENVIROMENT_VARIABLE value_of_environment_variable"

to

echo "NAME_OF_ENVIROMENT_VARIABLE=value_of_environment_variable"

(adding an equals sign)?

In line 380:

# often. I think ECL might need it, to just the option, not

change "to" to "so", I think.

As far as a careful review goes, I'm not enough of an expert in the Sage build process to do that. An expert should take a good look at this.

comment:6 follow-up: Changed 12 years ago by drkirkby

Thank you for the feedback. I'll make the couple o changes you suggest. I take your point about needing an expert of the build process. William and I wrote this many years ago, but its changed a lot since then.

If you have some spare time, (and I know building Sage can take some time), could you try a build with the sage-env script? First unpack the sources, then exchange spkg/base/sage-env for this one before trying a build. The build should proceed as normal. You might notice an extra -Wall or -g flag here or there, but there should be no huge changes.

What it will give is a bunch of variables that can at a later date be used inside files like spkg-install.

Dave

comment:7 in reply to: ↑ 6 Changed 12 years ago by jhpalmieri

Replying to drkirkby:

Thank you for the feedback. I'll make the couple o changes you suggest. I take your point about needing an expert of the build process. William and I wrote this many years ago, but its changed a lot since then.

One more question: should this also be included in sage-scripts? That is, should the file SAGE_ROOT/spkg/base/sage-env be the same as SAGE_ROOT/local/bin/sage-env? If so, please produce a patch for the scripts repository.

If you have some spare time, (and I know building Sage can take some time), could you try a build with the sage-env script? First unpack the sources, then exchange spkg/base/sage-env for this one before trying a build. The build should proceed as normal. You might notice an extra -Wall or -g flag here or there, but there should be no huge changes.

Sure, I'll start that right now.

comment:8 Changed 12 years ago by jhpalmieri

It built just fine on my OS X 10.6 machine. I'm trying on sage.math now (or boxen.math or whatever it is these days).

In case you missed my earlier question:

should this also be included in sage-scripts? That is, should the file SAGE_ROOT/spkg/base/sage-env be the same as SAGE_ROOT/local/bin/sage-env? If so, please produce a patch for the scripts repository.

comment:9 Changed 12 years ago by drkirkby

Note, there are still some occurrences of ;-a' and '-o' here. I tried not too change too much of the original file, to make the review somewhat easier. So some things I don't feel are perfect, I have left unchanged. They almost certainly make no difference whatsoever here, but its a good habbit to write scripts in such a way they work reliably, irrespective of what shell someone happens to use.

Dave

comment:10 Changed 12 years ago by drkirkby

  • Description modified (diff)

comment:11 Changed 12 years ago by drkirkby

  • Description modified (diff)
Note: See TracTickets for help on using tickets.