Peter Jeremy wrote:
> On 2009-Dec-29 13:51:43 +0000, "Dr. David Kirkby" <david.kir...@onetel.net> 
> wrote:
>> Then when I thought about it more, I do not know if its worth the hassle. Why
>> not simply ask the user to export SAGE64 to "yes" on Open Solaris, and forget
>> about a 32-bit build?
> 
> It looks like OpenSolaris/SPARC defaults to 32-bit mode (looking at the
> installed executables - I don't have a development system installed on
> my OSol box yet).

Yes it does. And I can understand why, since for 99% of programs, there is no 
advantage to 64-bit, but some disadvantages (larger pointers, let fit in cache 
etc).

But for Sage, I would have thought the only advantage of 32-bit would be the 
fact that gcc is less buggy. And I admit, that is a pretty significant 
advantage.

> Note that the current assumption that Sage is building in 32-bit mode
> unless 'SAGE64' is set is not universally true:  Tru64, FreeBSD/amd64
> and FreeBSD/SPARC64 (at least) default to building 64-bit executables
> and have minimal, if any, support for building 32-bit executables.

I'm not making that assumption.

>> http://trac.sagemath.org/sage_trac/ticket/7505
>>
>> could get a positive review and be integrated into Sage asap. Two people have
>> looked at it, and both agree it is OK.
> 
> I like the idea but the actual implementation seems somewhat convoluted.
> Why not make '${CC} -E ${TESTFILE}' directly output the wanted identifier,
> rather than running $CC multiple times and grepping for strings in the
> output.  This approach also seems likely to cause maintenance issues as
> changes need to be implemented in three places (including the usage).  I
> have attached a suggested alternative (testcxx could be similarly adapted).

I have not tested it, but I agree it is cleaner.

>> 1) Determine what compiler is in use by the use of the scripts in #7505
>> 2) Set CFLAGS to have the appropriate option for a 64-bit build in sage-env 
>> if
>> SAGE64 is set to "yes". That will be -m64 with Sun Studio or GCC, but will be
>> different for other compilers.
>> 3) Remove all the SAGE64 junk from every spkg-install, because:
>>  * It's unnecessary duplication
>>  * Currently has a mix of those that only work on OS X and those that work on
>>    Solaris, and those that only work on OS X.
>>  * It's incorrect to assume the flag to build 64-bit code will always be
>>    -m64, as some compilers use a different flag.
> 
> The code also needs to handle the situation where a 64-bit Sage will
> be built by default. 

I'm not convinced there needs to be anything to handle the case of 64-bit being 
built by default, unless we wish to be able to force 32-bit builds on platforms 
where 64-bit is the default.

If 64-bit is the default, one would not bother setting SAGE64, -m64 (or 
equivalent) flag would not get added, and the code should work. Have I 
overlooked something?

> Ideally, the 32 vs 64 bit code should be
> centralised and the relevant cc/c++/fortran/linker flags passed into
> each spkg-install.


I'm just in the process of trying to do that in sage-env

if [ "x$SAGE64" = "xyes" ] ; then
    if  [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xGCC" ] ; then
       # Flags for a 64-bit build.
       CFLAG64="-m64"
       CXXFLAG64="-m64"
       FCFLAG64="-m64"
    elif  [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xSun_Studio" ] ; then
       CFLAG64="-m64"
       CXXFLAG64="-m64"
       FCFLAG64="-m64"
    elif  [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xIBM_on_AIX" ] ; then
       #  http://www-01.ibm.com/support/docview.wss?uid=swg27012860&aid=1
       echo "The appropriate 64-bit option for IBM's C++ and Fortran"
       echo "compilers are assumed to be the same as the"
       echo "C compiler. This has not been checked"
       echo "Adding -q64 to generate 64-bit code"
       CFLAG64="-q64"
       CXXFLAG64="-q64"
       FCFLAG64="-q64"
etc

then later on:

    CFLAGS="$CFLAGS $CFLAG64"
    CXXFLAGS="$CXXFLAGS $CXXFLAG64"
    FCFLAGS="$FCFLAGS $FCFLAG64"

That way, we have as a variable (CFLAG64) in isolation, as well as in CFLAGS. I 
think ECL needs needed -m64 at one point during the link process, so not as a 
CFLAG.

We can also add in other things for a specific compiler, unrelated to 64-bit. 
One we need is the right flags for building shared libraries. I'd propose we 
call the flags a simpilar name to their GNU counterparts, so it makes 
substitution of hard-coded GCC-specific flags to variable names.

if  [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xGCC" ] ; then
     # These are the names of the environment variables, and their GCC
     # name. They are not appended to CFLAGS, CXXFLAGS or FCFLAGS as they
     # are not always needed.
     FPIC_FLAG="-fPIC "
     SHARED_FLAG="-shared"
     SONAME_FLAG="-soname"
     WHOLE_ARCHIVE_FLAG="--whole-archive"
     NO_WHOLE_ARCHIVE_FLAG="--no-whole-archive"

     # Enable warnings on gcc.
     CFLAGS="$CFLAGS -Wall"
     CXXFLAGS="$CXXFLAGS -Wall"
     FCFLAGS="$FCFLAGS -Wall"
elif  [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xSun_Studio" ] ; then
     # -xcode=pic32 is valid on 64-bit too, despite the name.
     # It is equivalent to the obsolete -KPIC on SPARC and -kPIC on x86
     # These flags for Solaris should work in most circumstances.
     # Identical flags have been used to build a 32-bit version of Sage
     # on SPARC.
     FPIC_FLAG="-xcode=pic32"
     SHARED_FLAG="-G"
     SONAME_FLAG="-h"
     WHOLE_ARCHIVE_FLAG="-z allextract"
     NO_WHOLE_ARCHIVE_FLAG="-z defaultextract"

Any thoughts on that?


dave

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to