On 2009-Oct-23 00:45:00 +0100, "Dr. David Kirkby" <david.kir...@onetel.net> wrote: >I had changed the wording somewhat anyway, but I would admit I had not >considered other applications.
I suspect that most potential users won't be able to dedicate a host to
Sage - especially if they are just trialling it. This implies that Sage
will need to co-exist with whatever else is running on the chosen host.
>I also added a check for the old sun4m and sun4c systems, as they can not be
>upgraded to Solaris 10.
Good point.
>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.
Agreed, but this implies that you still need to do some regression
testing on your application to verify that it still works.
>if test x$build_os = 'xsolaris5.0 || test x$build_os = 'xsolaris5.1' \
...
>|| test x$build_os = 'xsolaris5.7' || test x$build_os = 'xsolaris5.8' \
>|| test x$build_os = 'xsolaris5.9'
>then
How about:
os_major="${build_os%%.*}"
os_minor="${build_os#*.}"
os_minor1="${os_minor%%.*}"
if test "$os_major" \< "solaris5" -o \
\( "$os_major" = "solaris5" -a "0$os_minor1" -lt 10 \)
then
warn...
fi
OR
case "$build_os" in
solaris5.?|solaris5.?.*)
warn...
;;
esac
>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).
Not to mention the small memory configurations of those machines.
>> 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?
Short answer: To ensure ABI compatibility.
Long answer: When you compile code, the include files your code uses
map the API you used into the ABI provided by the associated library
files. When you specify '-lfoo' to the linker, it will search its
library path (builtin and specified via -L) for libfoo.so or libfoo.a.
The latter is a static library and relevant parts are simply embedded
into the resultant executable. The former is a shared library and the
linker just checks what symbols are defined and embeds the internal
name of the shared library into the executable. Normally, the
internal name is of the form libfoo.so.X or libfoo.so.X.Y, with
libfoo.so being a symlink to a real file by that name. The run-time
linker will search the runtime library paths for the (internal) shared
library name embedded in the executable.
Since you may be running the executable on a different system to that
on which the executable was compiled, there needs to be a way to
ensure that the ABI provided by the runtime library matches the ABI
expected by the application. This is done by adding version
information to the (internal) shared library name - ie the '.X' or
'.X.Y' (and, on modern systems, by versioning symbols within the
library). When an ABI change is made, the version number will be
changed (typically incremented). You can see the version information
for a given shared library by looking at the 'Version definitions'
output from 'objdump -p'.
>Would you limit that to assist in porting Solaris to just 9? Or would you
>include 8, 7, 2.6, 2.5 ...etc?
Systems earlier than Solaris 8 are probably fairly uncommon - and
hardware of that vintage is probably too slow to usefully run Sage.
Solaris 8 is still used but I'm not sure if there's the critical mass
to support Sage on them. IMO, it's up to people who want to run Sage
on a particular OS to demonstrate interest - if people pop up here
wanting (eg) a Solaris 7 port of Sage and put in the effort to identify
problems and fixes there there's no reason why there shouldn't be a
Solaris 7 port. OTOH, if one person turns up and wants a Solaris 8
port but is unable or unwilling to provide any assistance in producing
one then it's unlikely that there will be one.
>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.
The older Sun hardware on eBay does tend to be power-hungry and/or
slow . A decently optioned V240 or V245 would probably be usable -
though still a bit slow. Anything much older is probably too slow to
usefully build/test Sage and anything much bigger than a V440 is
probably too power-hungry for William's liking. There are a couple of
quad-CPU V440's on eBay in the $1.5-2.5K region and they draw
500-600W. I'm not sure how much (if any) rack/power/cooling William
has available (there are spare V440's at work but, unfortunately, I
can't think of any way to justify my employer making one available to
the Sage community).
>I would imagine producing a list of what libraries and programs are
>needed for every Sage package would be a very daunting task.
Running 'ldd' on each executable and shared library would be a decent
start, but runs the risk of missing a library that is dlopen'd but
required.
--
Peter Jeremy
pgpVRMfGkqHRW.pgp
Description: PGP signature
