Peter Jeremy wrote:
> On 2009-Oct-16 13:05:02 +0100, "Dr. David Kirkby" <david.kir...@onetel.net>
> wrote:
>> I'm updating a configure script which will warn users if their operating
>> system
>> is too old. In the case of a Solaris 9 machine it will say:
>
> Whilst I agree in principal, I have some concerns about the wording.
>
>> configure: WARNING: You are using Solaris 9, which is a very old version
>> configure: WARNING: last released in 2004. Solaris 10 was first released in
>> configure: WARNING: 2005, and there have been many updates since then. You
>> configure: WARNING: are advised to upgrade to Solaris 10 or later,
>
> This is all very nice in principal but may not be possible in practice
> due to requirements for other applications. Eg, we still have a Solaris
> 2.6 server to support an old application. Whilst the application might
> work with Solaris 10, that would require effort to upgrade the OS and
> then regression test the application - for which there is no funding.
I had changed the wording somewhat anyway, but I would admit I had not
considered other applications.
I also added a check for the old sun4m and sun4c systems, as they can not be
upgraded to Solaris 10.
I'm well there may be reasons for sticking to an older OS, though Solaris has
excellent binary compatibility. Obviously there are exceptions, but generally
it
it runs on version N, it will run on N+1, N+2 etc.
> I suspect you will find that Solaris 9 is still in fairly common use.
> Whether it's used widely enough to justify a Sage release, I'm not
> certain. (And I'm not certain how much effort would be needed to
> build Sage on Solaris 9).
I would agree Solaris 9 is in quite common use. If Wikipedia is to be trusted,
Solaris 9 will be supported by Sun until 2014, and even Solaris 8 to 2012. So
neither should be written off.
The current wording I have is:
if test x$build_os = 'xsolaris5.0 || test x$build_os = 'xsolaris5.1' \
|| test x$build_os = 'xsolaris5.2' || test x$build_os = 'xsolaris5.3' \
|| test x$build_os = 'xsolaris5.4' || test x$build_os = 'xsolaris5.5' \
|| test x$build_os = 'xsolaris5.5.1' || test x$build_os = 'xsolaris5.6' \
|| test x$build_os = 'xsolaris5.7' || test x$build_os = 'xsolaris5.8' \
|| test x$build_os = 'xsolaris5.9'
then
AC_MSG_WARN([*********************************************************])
AC_MSG_WARN([*********************************************************])
AC_MSG_WARN([You are using an older version of Solaris. ])
AC_MSG_WARN([Sage is only supported on Solaris 10 or later, though it ])
AC_MSG_WARN([may work on older releases. ])
if test "x`uname -m`" = 'xsun4m' || test "x`uname -m`" = 'xsun4c'
then
AC_MSG_WARN([Unfortunately, your hardware is too old to update to
])
AC_MSG_WARN([Solaris 10, so you may experience problems building
Sage.])
AC_MSG_WARN([In any case, it would be very slow on such old hardware.
])
else
AC_MSG_WARN([You can download the latest Solaris version free from])
AC_MSG_WARN([http://www.sun.com/software/solaris/])
fi
AC_MSG_WARN([*********************************************************])
AC_MSG_WARN([*********************************************************])
fi
but that is open to change of course.
(I believe the fastest processor from Sun for a sun4m machine was 85 MHz, and
while Ross made them up to 200 MHz for the Sun SPARC 10 and 20, they were not
particularly good. A think a 125 MHz Ross HyperSPARC is about the same speed or
a bit slower than a 75 MHz Sun SuperSPARC processor. Hence for all practical
purposes, building Sage on a sun4m or sun4c machine would be a pointless
exercise).
>> configure: WARNING: not supported on Solaris 9, though it may work (the Sage
>
> Actually, you can be fairly confident it won't work because the libm
> version was bumped between Solaris 9 and Solaris 10 so you will get
> a "libm.so.2 not found" error fairly quickly.
What in Sage would refer to the library by that name, and not simply libm?
> I would prefer a warning along the lines of:
> configure: ERROR: Sage is currently only supported on Solaris 10 and you
> configure: ERROR: are running an earlier version of Solaris. If you wish
> configure: ERROR: to assist in porting Sage to Solaris 9, please join the
> configure: ERROR: mailing list sage-devel@googlegroups.com
Would you limit that to assist in porting Solaris to just 9? Or would you
include 8, 7, 2.6, 2.5 ...etc?
Given used Sun hardware can be obtained very cheaply and Solaris obtained free,
there is somewhat less incentive to support older Solaris releases than there
might be older releases for systems which can not be upgraded to the latest
operating system, or where those updates cost money.
> BTW, the various Solaris 10 upgrades make fairly radical changes to
> the environment and I assume the build machines are running a fairly
> recent version of Solaris 10. Has anyone tried running the Solarris
> package on a early Solaris 10? It's possible there may be problems.
I have indeed set up a Sun Ultra 80 with the first release of Solaris 10 for
this very purpose. I can't recall exactly what did and did not work, but I know
ECL did not. I gave Juanjo (the main ECL developer) access to the machine, and
he made the necessary changes to ensure ECL would build on the first release of
Solaris 10.
I intend setting up a Sun Netra T1 in the next few days as a web server, and
will put the first Solaris release on that. I will leave that on 24/7, whereas
the power consumption of the Ultra 80 makes that very expensive.
I did suggest to William he get an old server from eBay for this very purpose,
but due to rack, power and cooling problems, he is unable to do this. Hence any
testing on older releases of Solaris would have to be done by hardware not
managed by William.
If we produce a binary for Solaris 10 on 't2', it is quite possible it will not
run on earlier releases of Solaris 10. It probably will, but it certainly not
guaranteed. Whereas if we build on the first release of Solaris 10, it will
with
a very high degree of certainty run on the latest. ('t2' would not run on the
first release of Solaris 10, so changing to an older OS is not an option).
>> I think I'll have to leave any tests for linux (or let someone else
>> write them), as I believe there are too many different distributions
>> to worry about.
>
> It would be nice to have a list of base OS shared libraries that Sage
> expects and do a check against the available libraries. I'm not sure
> how much effort this would be.
There are many things that are checked in configure scripts, but I do not know
what are actually needed. Does Sage need 'yacc' or 'bison' for example? If I
knew it did, then I could add a test for that early on, to save someone the
trouble of spending hours building Sage, only to find they need something which
we could have checked for earlier.
I would imagine producing a list of what libraries and programs are needed for
every Sage package would be a very daunting task. If each developer agreed to
document exactly what one package needed, then it would be possible. For for
any
single person to do so for 100+ packages would be too much to ask. I certainly
would not wish to do that.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
