On Jul 14, 5:44 pm, "Dr. David Kirkby" <[EMAIL PROTECTED]>
wrote:
> On 14 Jul, 19:20, mabshoff <[EMAIL PROTECTED]> wrote:
>
> > On Jul 14, 1:18 am, "Dr. David Kirkby" <[EMAIL PROTECTED]>
> > wrote:
>
> > Hi David,
>
> Hi Michael,
Hi David,
> > It will be one probably somewhat large spkg. When you build Sage on
> > Solaris it will recommend that you use it before anything else in Sage
> > is build. If you decide to use it it will either be installed in $HOME
> > somewhere or specficially into the current Sage install. I am planning
> > that the SFW in /usr/sfw is all that is required to build the custom
> > toolchain.
>
> It seems quite logical and sensible.
>
> > Yes, the requirement for root access would seriously hamper Sage on
> > Solaris, so it will work all self contained in $HOME. I do not have
> > root access on a number of Solaris boxen I test build Sage on, so it
> > could not work if root acccess were required.
>
> Again, we seem to have similar thoughts on that one.
>
> > One large appeal of Sage is that building it from source mostly
> > involved punching "make" into the command line and coming back after a
> > while. The toolchain would add about two hours on a fast machine to
> > this (and potentially much, much more on some slower Sparc box), but
> > since you can do it only once for a number of Sage installs that seems
> > much better for me since the debug environment will be consitent. It
> > is likely that we will need to upgrade the toolchain every once in a
> > while as time progresses, but so is the life of a software developer.
>
> You could probably cut down the time to build the tools by only
> building what is necessary - i.e. don't build compilers for all the
> obscure languages gcc supports - and builds by default. I assume you
> only need C, C++ and Fortran - there is no need for Java, Ada, object
> C, or whatever other obscure things gcc supports.
What I currently do is:
* build binutils 2.18 (slightly patched for x86/x86-64, but that
issue ought to be fixed in ATLAS's build system soon)
* build GNU make
* build gcc 4.2.4 with C, C++ and gfortran enabled
On Solaris 10 this ought to work with the sfw tools, but last time I
build I used gcc 4.3.1 from the system. In some cases I had to build a
C only gcc 3.4.6 before building any gcc 4.2.x or 4.3.x, but that was
on Solaris 9. Since I plan to support Solaris 10 and later only this
seems like a non-issue. If I switch to gcc 4.3.x I will end up having
to build gmp and mpfr, too, but in that case I could just (ab)use the
Sage spkgs.
> Parallel builds would be useful to speed up the build process on multi-
> processor machines. Virtually all the Suns I have here are either dual
> or quad processor, or dual core in the case of my laptop. One
> exception is a single processor rack-mount server.
Yeah, the interesting Sun boxen seem to mostly have a bunch of CPUs.
The smallest one I have access to has two phycisal CPUs.
> > Yep, the toolchain will be documented, i.e. what is build how and for
> > what purpose, so you could take the instructions and replicate what I
> > am doing automatically.
>
> Also consider that a system admin might build the tool chain once, and
> let multiple users use it, so ideally one would want the option of
> using the tools from a directory that is not part of $HOME/sage.
Sure, the central location toolchain build by the admin should also
work. It will likely be an option to source some script that sets up
the environment, so in the end we won't even depend on the toolchain I
provide. But it is likely that if something goes wrong and the fix is
non-obvious my first request would be to install the Sage toolchain
and rebuild Sage from scratch :)
> Dave
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
