Open Solaris - do we bother with 32-bit ?
Dr. David Kirkby
Xeon) and have a few problems.
The biggest headache seems to be the OpenSSL libraries. First they are not
shipped with Sage due to license issues. But neither do suitable libraries exist
as part of Open Solaris. They must be downloaded and built.
By default on Open Solaris, the OpenSSL lbiraries are built 64-bit. They pass
all tests in 64-bit mode.
If I try to force a 32-bit build of the OpenSSL libraries, they build, but fail
tests. I've asked on the OpenSSL mailing list how I can get a 32-bit library,
but so far have not got a response.
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?
We could force 64-bit by default, but in that case having a SAGE32 environment
variable would be very useful, as gcc tends to be less buggy on Solaris in
32-bit mode than it does in 64-bit mode.
It would really really help if
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. The scripts are not actually called in
any part of Sage, so it is hard to see how it can break Sage if the scripts are
not used. But by using them, we could make compiler options a lot less hassle.
I'm reluctant to go around endless .spkg files making sure the -m64 option is
added if SAGE64 is set to "yes", when I'm aware there is a much easier way. We
should simply:
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.
Dave
Peter Jeremy
>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).
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.
>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).
>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. Ideally, the 32 vs 64 bit code should be
centralised and the relevant cc/c++/fortran/linker flags passed into
each spkg-install.
--
Peter Jeremy
Dr. David Kirkby
> On 2009-Dec-29 13:51:43 +0000, "Dr. David Kirkby" <david....@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
Dr. David Kirkby
> 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.
I mean a *similar* name to the GNU counterparts, not a simpler name.
Dr. David Kirkby
> On 2009-Dec-29 13:51:43 +0000, "Dr. David Kirkby" <david....@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).
>
> 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.
>
>> 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've tested your much cleaner revised script with gcc, Sun Studio, HP's compiler
on HP-UX and then on an AIX 6.1 system I have been granted access by
http://www.metamodul.com/
AIX presented a bit of a problem:
-----------------------------------------
$ export CC=/usr/vac/bin/cc
$ ./testcc.sh
The license for the Evaluation version of IBM XL C/C++ Enterprise Edition V8.0
for AIX compiler product has expired.
-----------------------------------------
Perhaps letting the error message be displayed is the best way, rather than try
to force any other sort of output.
I do have an old IBM RS6000 here running AIX, but its only 32-bit, and would
take a bit of hassle to get it running. (Just like my IRIX and Tru64 machines
would). But the fact your changes still work with three different compilers
gives me confidence they will work with the others.
I'm not personally going to try to port Sage to AIX, but I want to avoid any
code which prevents someone else doing so. Making unnecessary assumptions the
the OS is X, Y or Z is not a good idea in my opinion.
> The code also needs to handle the situation where a 64-bit Sage will
> be built by default. 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 not aware the GNU linker takes any special argument for 64-bit. I know the
Sun linker can take -64 as an option,
---------------------------------------------
-64
Creates a 64-bit object. By default, the class of the
object being generated is determined from the first ELF
object processed from the command line. This option is
useful when creating an object directly with ld whose
input is solely from an archive library or a mapfile.
See The 32-bit link-editor and 64-bit link-editor in
Linker and Libraries Guide.
----------------------------------------------
but it is rarely needed.
If all this common stuff can be put in one or two files, then we wont have to
edit 100 spkg-install files if we find a different option is needed, or we want
to add support for another operating system.
dave
Dr. David Kirkby
>> 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).
Thank you very much Peter.
I must admit, your scripting skills are a lot better than mine. What is the
function of "E*O*F"? I'm impressed with this!
Anyway, I agree your revised version is much cleaner. I revised the C++ version
in a similar way. Could you have a quick look and see if you see anything wrong
with it. If not, I'll upload the revised C and C++ versions to the trac ticket.
I added you as an author, as clearly you have made a major contribution to
improving this.
Are you aware of any major compilers which are not covered? All the Intel/HP/Sun
compilers which are GCC-like will return 'GCC' which is fine. I can't think of
any other different compiler. Perhaps something like for the CUDA systems, but
that's a bit too specialised for now.
I'd like to get these into Saga asap, so I can work on making the code a bit
more portable, and sort out this SAGE64 mess, which is a pain on Solaris, as
some .spkg files use SAGE64 irrespective of the operating system, whereas others
ignore it on any platform except HP-UX.
dave
Peter Jeremy
>Peter Jeremy wrote:
>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).
OTOH, programs doing multi-precision integer math should benefit from
64-bit arithmetic - and I would expect that at least some parts of
Sage would benefit from this.
The crucial advantage of 64-bit is (effectively) unlimited address
space - if you need to manipulate more than ~2GB data then 64-bit
is the only way to go.
x86 vs x86_64 isn't as clearcut because the x86 architecture is so
badly designed - the relatively small number and lack of orthogonality
of registers and lack of a 16-bit relative addressing mode makes the
code relatively large for a 32-bit CISC architecture (it's close in
size to the RISC SPARC).
against it.
> I would have thought the only advantage of a 32-bit would be the
>fact that gcc is less buggy.
Whilst this may be true for SPARC, I haven't seen any sign of it with x86_64.
>> Note that the current assumption that Sage is building in 32-bit mode
>> unless 'SAGE64' is set is not universally true:
>I'm not making that assumption.
Sorry. I wasn't implying that _you_ were, only that parts of Sage do.
As an example, readline-6.0.p1/spkg-install contains:
if [ "x$SAGE64" = "xyes" ] || [ "x$SAGE64" = "x1" ] ; then
echo "Building a 64-bit version of Readline"
...
else
echo "Building a 32-bit version of Readline"
fi
>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?
Only that parts of the code then claim to be building a 32-bit version.
So far, I haven't found any issues caused by this.
>if [ "x$SAGE64" = "xyes" ] ; then
> if [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xGCC" ] ; then
...
> elif [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xSun_Studio" ] ; then
...
> elif [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xIBM_on_AIX" ] ; then
...
You might like to look for 'case ... esac' in your sh(1) documentation.
>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.
'-m64' or similar will also need to be passed to the link step - LDFLAGS
is normally used for this.
> # -xcode=pic32 is valid on 64-bit too, despite the name.
The '32' actually refers to the size of the relocation field. There's
also pic13 on SPARC - which is significantly faster than pic32 when it
can be used. gcc also has '-fPIC' and '-fpic' for different relocation
sizes.
>Any thoughts on that?
I'm all for centralising as much as possible. My only concern is that
things like PIC choices should ideally be a combination of the compiler
(-fPIC/-fpic or -xcode=pic32/-xcode=pic13) and library (-fpic or
-xcode=pic13 if possible).
On 2009-Dec-30 00:57:27 +0000, "Dr. David Kirkby" <david....@onetel.net> wrote:
>I'm not aware the GNU linker takes any special argument for 64-bit. I know the
>Sun linker can take -64 as an option,
The cc/gcc/g++/ld/... command that actually does the linking needs the
'-64' or '-m64' flag to tell it to create a 64-bit executable, otherwise
SunStudio (at least) will default to 32-bit mode and complain about
ELF mismatches.
On 2009-Dec-30 02:17:25 +0000, "Dr. David Kirkby" <david....@onetel.net> wrote:
>I must admit, your scripting skills are a lot better than mine. What is the
>function of "E*O*F"? I'm impressed with this!
sh(1) supports an input redirection of the form '<< word' which takes
the content of the shellscript until the next occurrence of 'word' at
the beginning of a line and uses it as stdin for that command. I suggest
you read the relevant shell documentation and have a play (there are
options to control parameter expansion and leading TAB stripping).
>Anyway, I agree your revised version is much cleaner. I revised the
>C++ version in a similar way. Could you have a quick look and see if
>you see anything wrong with it.
I swapped the test for $CC and the usage report because I felt it was
more reasonable to provide a usage message if $CC wasn't set than
complain that $CC is unset.
A shorter alternative to the test would be:
: ${CC:?Sorry, you should define the environment variable CC}
>I added you as an author, as clearly you have made a major contribution to
>improving this.
Thank you.
>Are you aware of any major compilers which are not covered?
No. I have access to a Tru64 system at work but I won't be back to work
for a couple of weeks. I think that anything not currently covered is
going to need non-trivial porting effort elsewhere and detecting those
compilers can be done as part of that effort.
--
Peter Jeremy
Robert Bradshaw
> On 2009-Dec-29 23:57:13 +0000, "Dr. David Kirkby" <david....@onetel.net
> > wrote:
>> Peter Jeremy wrote:
>> 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).
>
> OTOH, programs doing multi-precision integer math should benefit from
> 64-bit arithmetic - and I would expect that at least some parts of
> Sage would benefit from this.
Yep, 64-bit based multi-precision can be up to 4 times as fast. And
unlike most of the world, users of Sage use their computers to
actually compute.
> The crucial advantage of 64-bit is (effectively) unlimited address
> space - if you need to manipulate more than ~2GB data then 64-bit
> is the only way to go.
For sure, and we do this all the time :).
> x86 vs x86_64 isn't as clearcut because the x86 architecture is so
> badly designed - the relatively small number and lack of orthogonality
> of registers and lack of a 16-bit relative addressing mode makes the
> code relatively large for a 32-bit CISC architecture (it's close in
> size to the RISC SPARC).
> against it.
I was under the impression that x86-64 actually tried to resolve some
of the x86 cruft (e.g. adding more registers and increasing their
flexibility), though of course it's still rather constrained due to
backwards compatibility requirements.
- Robert
Peter Jeremy
>On Dec 29, 2009, at 9:14 PM, Peter Jeremy wrote:
>> x86 vs x86_64 isn't as clearcut because the x86 architecture is so
>> badly designed - the relatively small number and lack of orthogonality
>I was under the impression that x86-64 actually tried to resolve some
>of the x86 cruft (e.g. adding more registers and increasing their
>flexibility), though of course it's still rather constrained due to
>backwards compatibility requirements.
Sorry, I meant that x86_64 has various benefits (like additional, useful
addressing modes and additional, orthogonal registers) that at least
partially mitigate the 64-bit downsides - unlike (eg) SPARC. As a
quick check, summing the .so's in OpenOffice (a typical kitchen sink
application), I get:
Text Data BSS Total
x86: 142662399 8040404 421452 151124255
x86_64: 196508472 15792668 696304 212997444
--
Peter Jeremy
Dr. David Kirkby
> On 2009-Dec-29 23:57:13 +0000, "Dr. David Kirkby" <david....@onetel.net> wrote:
>> Peter Jeremy wrote:
>> 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).
>
> OTOH, programs doing multi-precision integer math should benefit from
> 64-bit arithmetic - and I would expect that at least some parts of
> Sage would benefit from this.
>
> The crucial advantage of 64-bit is (effectively) unlimited address
> space - if you need to manipulate more than ~2GB data then 64-bit
> is the only way to go.
I guess I did not make it clear, but I was implying that Sage was a program in
the 1% category where there are significant advantages to 64-bit.
> x86 vs x86_64 isn't as clearcut because the x86 architecture is so
> badly designed - the relatively small number and lack of orthogonality
> of registers and lack of a 16-bit relative addressing mode makes the
> code relatively large for a 32-bit CISC architecture (it's close in
> size to the RISC SPARC).
> against it.
>
>> I would have thought the only advantage of a 32-bit would be the
>> fact that gcc is less buggy.
>
> Whilst this may be true for SPARC, I haven't seen any sign of it with x86_64.
Fair enough - I've more experience of SPARC than of x86.
I had forgot one other advantage of supporting 32-bit, in that Open Solaris does
run on 32-bit hardware.
I can imagine there are a fair number of PCs in use with 32-bit processors, but
I would have thought anyone installing Open Solaris and wanting to build Sage,
would have used a 64-bit machine.
If you have a 64-bit system, Open Solaris will boot a 64-bit kernel by default.
It might be possible to change that, but I doubt many will want to. We do not
have the resources to test on many systems.
The OpenSSL libraries are building by default in 64-bit mode on my Sun Ultra 27:
------------------------------------------------
bash-3.2$ ./config
Operating system: i86pc-whatever-solaris2
Configuring for solaris64-x86_64-gcc
Configuring for solaris64-x86_64-gcc
<SNIP>
making links in fips/hmac...
fips_hmactest.c => ../../test/fips_hmactest.c
generating dummy tests (if needed)...
Configured for solaris64-x86_64-gcc.
bash-3.2$
------------------------------------------------
My attempts to chose a different target from the default (solaris-x86-gcc seemed
the only semi-plausible alternative), resulted in a pretty quick failure of the
test suite.
As such, I personally believe the best approach on Intel/AMD machines would be to:
1) Assume people run 64-bit.
2) Export SAGE64
3) Build a 64-bit version of OpenSSL (the default)
4) Change the broken spkg-install files to remove the restriction in many, that
-m64 is added only the operating system is OS X.
>>> Note that the current assumption that Sage is building in 32-bit mode
>>> unless 'SAGE64' is set is not universally true:
>> I'm not making that assumption.
>
> Sorry. I wasn't implying that _you_ were, only that parts of Sage do.
> As an example, readline-6.0.p1/spkg-install contains:
>
> if [ "x$SAGE64" = "xyes" ] || [ "x$SAGE64" = "x1" ] ; then
> echo "Building a 64-bit version of Readline"
> ...
> else
> echo "Building a 32-bit version of Readline"
> fi
I might have written that bit of code, though I thought it had been removed. I
was under the impression at one point that not setting SAGE64 to yes would
result in a 32-bit build, but I now know that is not true.
>> if [ "x$SAGE64" = "xyes" ] ; then
>> if [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xGCC" ] ; then
> ...
>> elif [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xSun_Studio" ] ; then
> ...
>> elif [ "x`$SAGE_LOCAL/bin/testcc.sh`" = "xIBM_on_AIX" ] ; then
> ...
>
> You might like to look for 'case ... esac' in your sh(1) documentation.
Cheers, though I might be inclined to leave that, as I've almost finished what I
intended doing on sage-env.
I think I need to buy a book on shell scripting. Mine is better than a lot of
the things in Sage, but clearly I know a lot less you.
>> 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.
>
> '-m64' or similar will also need to be passed to the link step - LDFLAGS
> is normally used for this.
>
>> # -xcode=pic32 is valid on 64-bit too, despite the name.
>
> The '32' actually refers to the size of the relocation field. There's
> also pic13 on SPARC - which is significantly faster than pic32 when it
> can be used. gcc also has '-fPIC' and '-fpic' for different relocation
> sizes.
>> Any thoughts on that?
>
> I'm all for centralising as much as possible. My only concern is that
> things like PIC choices should ideally be a combination of the compiler
> (-fPIC/-fpic or -xcode=pic32/-xcode=pic13) and library (-fpic or
> -xcode=pic13 if possible).
I do not understand the difference. But I believe most, if not all of the code
generated by libtool is using -KPIC if one uses the Sun compiler. -KPIC is
equivalent to -xcode=pic32.
Where would you decide whether to use xcode=pic32 or xcode=pic13? Would that
mean evaluating every package on an individual basis? I do not what to limit
performance unnecessarily, or make it hard for anyone to do so in the future,
but I feel the simpler this can be kept, the better here.
The current situation with tons of hard-coded -fPIC, -soname, -shared etc is not
ideal.
> I swapped the test for $CC and the usage report because I felt it was
> more reasonable to provide a usage message if $CC wasn't set than
> complain that $CC is unset.
OK, will do so too in testcxx.sh
Dave
Dr. David Kirkby
> On Dec 29, 2009, at 9:14 PM, Peter Jeremy wrote:
>
>> On 2009-Dec-29 23:57:13 +0000, "Dr. David Kirkby" <david....@onetel.net
>>> wrote:
>>> Peter Jeremy wrote:
>>> 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).
>> OTOH, programs doing multi-precision integer math should benefit from
>> 64-bit arithmetic - and I would expect that at least some parts of
>> Sage would benefit from this.
>
> Yep, 64-bit based multi-precision can be up to 4 times as fast. And
> unlike most of the world, users of Sage use their computers to
> actually compute.
Yes. That's my main reason for suggesting not to bother with 32-bit on Open
Solaris.
I'm not suggesting we force 64-bit on anyone by hard-coding -m64 everywhere.
That would be the most stupid thing to do. But we simply don't waste time on
problems which only occur in 32-bit mode.
Currently Sage does not build on Open Solaris. Some unresolved issues are
specific to 32-bit (OpenSSL being one), some unresolved issues are specific to
64-bit (numerous spkg-install files).
But given a lack of resources, I believe we should concentrate building Sage in
a way likely to be of benefit to most people - i.e. a 64-bit build.
I'm a bit reluctant to fight with OpenSSL when a 64-bit Sage would be more
useful to me.
Dave