Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#11077 closed enhancement (invalid)

revise the script sage-check-64

Reported by: jhpalmieri Owned by: GeorgSWeber
Priority: minor Milestone: sage-duplicate/invalid/wontfix
Component: build Keywords: 64-bit script
Cc: Merged in:
Authors: Reviewers: Jeroen Demeyer
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description

The script sage-check-64 should be revised:

  • it should help to protect users who for example set SAGE64="no", build Sage partially, set SAGE64="yes", and resume the build.
  • it should behave better with platforms other than Mac OS X and Solaris: right now, it silently accepts setting SAGE64=yes on any platform, resulting in extra compiler flags being passed in some spkgs. Should it only pass these flags this on Mac OS X and Solaris? If not, should it write the file SAGE_ROOT/local/lib/sage-64.txt on any platform?
  • should the status of the build, 32-bit or 64-bit, be stored in the aforementioned file sage-64.txt on any platform, whether or not SAGE64 is set?
  • should the variable SAGE64 be renamed to something more descriptive like SAGE_FORCE_64_BIT_BUILD?

See #10303 for further discussion.

Change History (3)

comment:1 Changed 10 years ago by drkirkby

[John Palmieri wrote in the description] The script sage-check-64 should be revised:

  • it should help to protect users who for example set SAGE64="no", build Sage partially, set SAGE64="yes", and resume the build.

I'm not aware of anywhere that the documentation says to set SAGE64=no. Is there a case for setting this to "no" If so, what would this do? If we added the -m32 flag everywhere, that would break various bits of code.

However, I do agree that once a build is started without SAGE64 being set to "yes", then we should not allow a build to be restarted with it set, as that produces a mix of 32-bit and 64-bit objects.

  • it should behave better with platforms other than Mac OS X and Solaris: right now, it silently accepts setting SAGE64=yes on any platform, resulting in extra compiler flags being passed in some spkgs. Should it only pass these flags this on Mac OS X and Solaris? If not, should it write the file SAGE_ROOT/local/lib/sage-64.txt on any platform?

I think it would be most unwise to limit this to just OS X and Solaris. Firstly, it could be useful on other platforms like AIX. Combined with CFLAG64 it can be used with commercial compilers on both AIX and HP-UX. It can also be used as an aid to debugging Linux issues. See the posts on sage-support when I discovered someones 64-bit computer was building 32-bit objects on Linux. I suggested he set SAGE64=yes. He later posted his results:

gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)
****************************************************
Creating a 64-bit version of GNU patch
checking for gcc... gcc
checking for C compiler default output... configure: error: C compiler cannot create executables
See `config.log' for more details.
Error configuring GNU patch

real    0m0.129s
user    0m0.043s
sys     0m0.095s
sage: An error occurred while installing patch-2.5.9

That incidentally highlights a bug in bzip2, as that built 32-bit on linux, even with SAGE64 set. That is now #11107.

  • should the status of the build, 32-bit or 64-bit, be stored in the aforementioned file sage-64.txt on any platform, whether or not SAGE64 is set?

Yes. It would need some though on how best to do it though. Perhaps the "prereq" script is the place to do this. Just test for the sizeof(long).

  • should the variable SAGE64 be renamed to something more descriptive like SAGE_FORCE_64_BIT_BUILD?

I agree SAGE64 is not a good name and SAGE_FORCE_64_BIT_BUILD would be better.

Though perhaps long-winded, SAGE_FORCE_64-BIT_BUILD_ON_PLATFORMS_DEFAULTING_TO_32-BIT would make it clearer exactly what the environment variable does, and stop people setting it by mistake, thinking they need it to get a 64-bit build on Linux.

However, whilst I agree SAGE64 was a bad choice, there's no easy way of changing the variable everywhere

  • Sage library
  • Information on Wiki's.
  • Sage documentation.
  • All .spkgs. The .spkg's could be done on an automated process, using a simple script, if the release manager did the following:
    • All the changes on one ticket, with one commit message on each .spkg.
    • SPKG.txt was not updated.
    • The version of the .spkg was not updated.

Does the change of name warrant the hassle of changing it?

See #10303 for further discussion.

I just feel that ticket has got too complex to review - at least for me.

I agree references to 64-bit are being produced too often. On a 64-bit build of Sage on OpenSolaris, with a bit of hand-editing of a C++ file to resolve a core dump, I see unnecessary and inaccurate 64-bit junk every time Sage is started.

drkirkby@hawk:~/try/sage-4.7.alpha2$ ./sage
Building Sage on Solaris in 64-bit mode
Creating SAGE_LOCAL/lib/sage-64.txt since it does not exist
Detected SAGE64 flag
Building Sage on Solaris in 64-bit mode
----------------------------------------------------------------------
| Sage Version 4.7.alpha2, Release Date: 2011-03-21                  |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
**********************************************************************
*                                                                    *
* Warning: this is a prerelease version, and it may be unstable.     *
*                                                                    *
**********************************************************************
sage: 

PS, even if we store this file, I don't think $SAGE_LOCAL/lib is the place to store it. A text file is not a library.

Dave

comment:2 Changed 9 years ago by jdemeyer

  • Resolution set to invalid
  • Reviewers set to Jeroen Demeyer
  • Status changed from new to closed

Some of these were fixed at #12789. Given the vague description and no activity on this ticket, I'm going to close this.

comment:3 Changed 9 years ago by jdemeyer

  • Milestone changed from sage-5.3 to sage-duplicate/invalid/wontfix
Note: See TracTickets for help on using tickets.