On 07/10/10 02:32 PM, Sergey Bochkanov wrote:
Hello, David!
Thanks for your reply, it was very useful.
You wrote 10 июля 2010 г., 1:47:31:
1) It does not work on Solaris 10 on SPARC - see below. I suspect
there are some GNU-specific linker options, which will fail if the
Sun linker is used on Solaris 10.
Looks like it is actually the case.
Ideally you would have a test to see if gcc is using the Sun or GNU linkers. We
have actually just checked what's the first linker in the path, but it is far
from optimal. If its possible to use compiler options, rather than linker
options, then that's less hassle. Most packages do not call the linker directly,
but a few do. (Or course, calling via the -Wl,-foobar) option passes the option
foobar directly to the linker.
However ALGLIB, is not respecting the SAGE64 variable, so despite
SAGE64 being set to "yes", only a 32-bit binary was made. (This was
on a Sun Ultra 27, with a Xeon processor running OpenSolaris
06/2009.)
OK, will fix it. But I've though that you just add corresponding
options to CFLAGS automatically.
No. In fact, setting some quite reasonable CFLAGS and CXXFLAGS will break the
Sage build - Cython does not like them. It should all be handled from
spkg-install via the SAGE64 environment variable. We have also started using the
variable CFLAG64 (see in GPLK for an example), so the compiler flag for 64-bit
does not have to be -m64, but can be whatever the user wants. This is helpful,
as some compilers on operating systems like HP-UX and AIX do not use -m64. That
said, there are currently no ports to AIX or HP-UX, though there's been a bit of
work on it. I've done a bit on porting to HP-UX, but my main aim it to get an
OpenSolaris build, and a 64-bit SPARC build. (At the minute, Sage does not build
64-bit on SPARC, but it should not be too much effort to get that to work. It is
one of my fairly short term aims).
Note also, Sage usually puts shared libraries in $SAGE_LOCAL/lib and
does not create directories like "alblib-bin" off of $SAGE_LOCAL.
OK, will fix it too. Now I see that separate directory is in fact
unnecessary.
An odd few programs do create subdirectories, but they do it off of
$SAGE_LOCAL/lib or $SAGE_LOCAL/include.
I was impressed you had put the spkg-check file. As you can see, it
does pass all tests. On my Sun Ultra 27, it takes 8.2 seconds to
install, and 2 minutes and 1 second to both install and run the test
suite.
Good.
Is it OK for SAGE to have spkg which takes 2 minutes to test? Just
don't know what are the timing requirements. You have a lot of
packages, and testing ALL of them will take a lot of time.
Sure in spkg-check. That is not an issue. But not in spkg-install.
I personally think some of the self-tests should be run from spkg-install, if
they are very quick. Some take only a couple of seconds. But the current 'rule'
is they are not run. An exception is 'mpir' since that tends to find a lot of
compiler bugs.
I think it would be better if the test suite gave some feedback
after each test, rather than just at the end.
Actually, it prints results line by line. I think that the reason is
lack of flush() calls; it worked on Window and Linux, but different
systems (and even different distros) may have different output
buffering strategies. I'll to fix it.
Yes. quite possibly. William will give you access to a SPARC I am sure, which
will aid testing.
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
